Two Days of Data Entry, Gone

How a multi-clinic dental group turned a two-day, all-hands month-end into ninety minutes of work for one person — and why the answer wasn't "just write a script" or "just use AI."

---

Dental groups are an accounting problem disguised as a healthcare business

If you run a single clinic, month-end is manageable. One location, a handful of practitioners, a predictable stack of invoices.

Now add seven more clinics.

Suddenly you have dentists rotating across locations, each on their own arrangement. You have labs, suppliers, and equipment vendors billing per site. You have expenses that need to land against the right clinic, the right doctor, and the right cost line — because that's what determines who gets paid what.

None of this is intellectually difficult. There's no strategy in it, no judgement call worth a partner's time. It's simply that the number of small, correct decisions required each month scales with clinics × doctors × vendors, and a human being has to make every single one of them by hand.

This is why multi-branch dental groups end up with administrative teams that look oversized for the revenue they support. It isn't bloat. It's arithmetic.

The part that makes it genuinely hard

Here's what most people miss when they look at this problem and think surely you can automate that.

The doctor-to-clinic mapping is not fixed.

Some dentists work at one clinic. Some work at four. Some cover three of four this month and one of four the next. Locum arrangements shift. A specialist picks up an extra site for six weeks. Someone goes on leave and their sessions get redistributed.

So the structure of the reconciliation itself changes every month. It is not a stable table waiting to be filled in — the rows change. Which doctor-clinic combinations are live, and therefore which cells need to exist and be populated, is something you can only determine from that month's actual data.

That single fact is what defeats the obvious solutions.

What the work actually looked like

A staff member opens an invoice. She reads it. She identifies the clinic, the practitioner, the date, the line items, the amount. She switches to a spreadsheet. She works out which tab, which row, which cell — given who worked where this month. She keys it in. She checks she hasn't fat-fingered a digit. She closes the invoice.

Then she does it again. And again. For two days, across an entire team, every month.

There's nothing wrong with the people doing this. They're doing it correctly, which is the hard part. The problem is that it's a machine's job being done by trained finance staff, and it carries three costs the org chart doesn't show:

An error surface. Thousands of manual transcriptions a month means a non-zero number of wrong cells. Those errors surface weeks later, in a payout dispute with a dentist, and cost far more to unwind than they did to make.

A bottleneck. Nothing downstream — payouts, reporting, decisions — moves until the keying is done. Month-end doesn't start when the month ends. It starts when data entry finishes.

Your best admin staff. The people who understand the business well enough to spot a genuine anomaly spend two days a month proving they can copy numbers accurately.

Why the two obvious answers both fail

"Just write a script."

Scripts are excellent at consistency and hopeless at variation. A script has to be told in advance what an invoice looks like and which doctor-clinic pairs exist. Neither holds here. Every new vendor layout, every changed rotation, every new arrangement becomes a code change. You'd spend more time maintaining rules than the rules ever saved you. This is the graveyard most in-house automation attempts end up in.

"Just point an AI at it."

Large language models are the mirror image: superb at variation, unreliable at consistency. Same input, two runs, two answers — perhaps both plausible, perhaps one quietly wrong. That's a tolerable trade for drafting an email. It is not tolerable when the output determines what a dentist gets paid.

It's also unauditable. Ask a pure-AI system why a particular number landed in a particular cell and the honest answer is the model decided. No finance function should accept that, and no accountant should be asked to sign off on it.

What we actually built

We split the problem by which property each part of it needs.

Where the work varies, we use AI. Reading an invoice of unknown layout. Pulling out practitioner, site, date, line items, amounts. Interpreting the awkward ones. This is exactly the kind of judgement that defeats a script, and exactly what a model is good at.

Where the work must never vary, we use code. All arithmetic. All aggregation. All routing — which tab, which row, which cell. All reconciliation totals. Deterministic, inspectable, identical on every run.

And the structure is derived, not assumed. The workflow works out from the month's own data which doctor-clinic combinations are actually live, then builds the output to match. It doesn't need to be told that Dr. Lim covered three sites in March and one in April. It reads that out of the data.

Every AI call in the workflow is narrow and single-purpose, and returns something that can be checked — not a finished document. Anything the workflow can't resolve confidently is flagged for a person rather than guessed at. In accounting, a system that stops and asks is worth ten that silently invent an answer. The exceptions are the only thing anyone needs to look at, and there are few enough that reviewing them is a coffee-length task rather than a two-day one.

The result of that architecture is the thing that actually matters: speed and consistency at the same time. Run it twice, get the same answer twice. That isn't a property of the model. It's a property of the design — and it's the guarantee no pure-AI tool can make, because non-determinism is baked into what those tools are.

What we deliberately did not do

We didn't change their process. Their spreadsheet was built over years around how their group actually operates. Rebuilding it to suit our tooling would have been our convenience, purchased with their disruption. The workflow adapts to their format, not the reverse.

We didn't ask them to learn anything. No dashboard to master, no prompts to write, no configuration to maintain, no AI literacy required from anyone in the building. When something needs changing, they tell us and we change it.

We didn't hand them a tool and a manual. We own the workflow. We monitor it. When a vendor changes their invoice layout or a new clinic comes online, that's our problem to solve, not a support ticket they have to chase.

Their entire client-facing surface is this: upload the invoices, run the workflow. One folder and one button.

What happens when something changes

Something always changes. A lab sends its invoices in a new layout. A new clinic opens. A dentist starts covering a site they've never worked at. Each of these can break a workflow, or worse, leave it running and quietly putting a number in the wrong cell.

So the work didn't end at launch. We watch every run. When something changes, our team finds what changed, updates the workflow, and runs the update again on real invoices to check the totals still match before it goes live. Because these figures decide what a dentist is paid, no change to this workflow goes live without a person checking the result first.

The group's side of it stays the same: one folder, one button. If a run needs attention, we tell them what happened and what we changed. (Why automations break, and who fixes them.)

The result

Before: two full days, an entire administrative team, every month.

After: one to two hours, one person.

The staff who used to spend those two days keying invoices went back to work that requires a person — chasing genuine discrepancies, handling vendors, supporting the clinics. The month-end bottleneck stopped being a bottleneck. And the group's financial picture now arrives in days rather than weeks, which changes what you can actually do with it.

If this shape sounds familiar, it probably is yours

Nothing here is specific to dentistry. The shape is:

• Multiple branches or sites, each generating its own paperwork
• Distributed practitioners, contractors, or crews whose pay depends on correctly attributed data
• Assignments that change from month to month, so no fixed template survives
• A recurring cycle where the same manual work repeats identically
• A spreadsheet somewhere that everything eventually has to land inside

That describes dental and medical groups. It also describes field-service companies with technicians across sites, freight forwarders reconciling carrier invoices, property firms managing multiple buildings, M&E contractors handling subcontractor claims, and wholesale distributors processing supplier billing.

If your team spends days each month moving numbers out of documents and into cells, that work already has a price and you're already paying it. The only question is whether you keep paying it every month.

Talk to us

Scribe.sg builds custom AI workflows once and keeps them working. You tell us the problem. We handle the rest: understanding it, building it, checking it with you on your own data, running it, fixing it when something changes, and expanding it as the business grows.

You don't need to know anything about AI. That's rather the point.