The Automera blog.

RPA is very good at one thing: repeating a sequence of clicks and keystrokes exactly as it was recorded. That's genuinely useful until the screen changes, or the invoice arrives in a format nobody anticipated.

The brittleness problem

Most RPA failures we see aren't crashes. They're silent: the bot keeps running, but it puts the wrong number in the wrong field because a dropdown moved. Someone notices three weeks later during reconciliation.

Traditional RPA has no model of what it's doing. It doesn't know an invoice from a purchase order. It only knows that the third field on the second row is usually the amount.

What IPA adds

• Understanding document AI reads the content, so the bot knows what it's looking at.
• Judgement decision rules and confidence thresholds let a workflow branch instead of blindly proceeding.
• Escalation when confidence drops, the item goes to a human with the evidence attached.

A practical migration path

You don't throw away your bots. Keep the reliable click sequences for systems that never change, and put an intelligence layer in front of them. The bot still types into the ERP it just gets a validated, structured record instead of a guess.

The measurable difference: exception rates fell from roughly 1 in 12 to 1 in 90 for teams that made this shift, because the automation stopped guessing.

A new hire's first day should be about people, not paperwork. Yet at most companies it's the opposite: six hours of forms, accounts, and waiting.

What actually takes six hours

We mapped one mid-sized company's onboarding process and found 34 discrete steps across HR, IT, Finance, and Facilities. Fourteen of them were pure data entry the same name, the same NIC number, typed into a different system each time.

The rebuild

The team kept the human steps the welcome, the buddy assignment, the first-week check-in and automated everything else:

• Offer acceptance triggers a single record that all downstream systems read from.
• Email, ERP, and building access accounts are created automatically with role-appropriate permissions.
• Statutory registration forms are pre-filled and queued for signature.
• Asset allocation raises a ticket with IT and books the device to the employee record.

Total hands-on time dropped from six hours to about twelve minutes and most of that twelve minutes is a human double-checking the generated record before it goes out.

The goal was never zero humans. It was zero re-typing.

The unexpected benefit: new hires now have working accounts before they walk in, which removed the awkward first-day dead time entirely.

When we crossed 400,000 classified tickets, we went back through the data to find out what actually moved the needle and what we'd been wrong about.

Accuracy is the wrong first metric

Our first model hit 81% top-1 accuracy and nobody was happy. The reason: a wrong route costs more than an unclassified ticket. An unclassified ticket goes to a human triage queue, which is fine. A misrouted ticket goes to the wrong engineer and sits there for a day.

So we optimised for precision at the threshold, not raw accuracy. Anything below 0.7 confidence goes to triage instead of being auto-routed.

What the data told us

• Subject lines matter more than bodies. Truncating the body to 200 characters lost almost nothing.
• Historical resolution text is a goldmine. Adding the closing note from similar past tickets was the single biggest accuracy gain.
• Category drift is real. New products create new categories. The model needs retraining on a quarterly cadence, not yearly.

The result

With a 0.7 threshold, 68% of tickets route automatically at 96% precision. The remaining 32% go to human triage which sounds like a lot until you realise triage now takes 40 seconds per ticket instead of four minutes, because the model surfaces the three most likely categories with evidence.

Until now, every workflow followed a single path. That's fine for simple jobs, but real business processes branch constantly a LKR 50,000 invoice doesn't need the same approval chain as a LKR 5 million one.

How it works

Drop a decision step anywhere in the flow and define conditions using any field available at that point: extracted document values, form inputs, dates, user roles, or custom variables.

• Amount thresholds route by value, with as many bands as you need.
• Text matching branch on keywords, supplier names, or document types.
• Date logic handle month-end, grace periods, and SLA deadlines.
• Combined conditions AND/OR groups for the messy real-world cases.

What it replaces

Most teams were faking this with separate workflows per scenario, which meant five near-identical flows to maintain. Now it's one flow with a decision step, and a change to the threshold applies everywhere at once.

Decision rules are available on all plans today, and existing workflows keep running unchanged until you edit them.

Automation makes processes faster. It does not, by itself, make them auditable. In fact, a badly built workflow can make an audit worse because now nobody remembers who did what.

The three questions an auditor asks

• Who approved this, and in what role?
• When and was that within policy?
• On what basis what did they see when they decided?

A chat message saying "yeah go ahead" answers none of these. Neither does an automated approval with no attached evidence.

Building it in from the start

Every approval step should capture the identity of the approver, a timestamp from a trusted source, the exact version of the document they reviewed, and any comment they left. That record should be immutable and exportable.

If reconstructing an approval takes more than two minutes, your audit trail isn't real.

We also recommend a separate, non-blocking audit log that records what the automation itself did extractions, confidence scores, and escalation decisions. When an auditor asks why an invoice was auto-approved, you can show the confidence score and the rule that matched.

The payoff

Teams with proper trails report audit preparation dropping from weeks to days, and far fewer follow-up questions because the evidence is already attached to the transaction.

A provisioning request used to take three days. Not because the work was hard the actual provisioning takes eleven minutes but because it bounced between a ticket queue, a capacity check, and a manager's inbox.

The old path

Request submitted → wait for triage → engineer checks available capacity manually → cost estimate emailed to manager → manager approves by reply → engineer provisions → ticket closed. Seven handoffs, three of them pure waiting.

The new path

• Requester fills a form specifying environment, size, and duration.
• The workflow queries the capacity API and attaches live utilisation data.
• Cost is calculated from the same rate card Finance uses, so numbers always agree.
• If cost is under the threshold, it auto-approves; otherwise it routes to the right budget owner.
• On approval, infrastructure is provisioned and the requester gets credentials and a decommission date.

Elapsed time: under an hour in the common case, and that hour is mostly the requester deciding what they want.

What made it safe

The workflow never provisions without a capacity check, and it always sets an expiry. That one detail eliminated the "forgotten test server running for eight months" problem that had been quietly inflating the cloud bill.

OCR has been "solved" for about fifteen years, according to people who have never processed a real Sri Lankan supplier invoice.

Where it breaks

• Tables without borders. OCR reads across columns and produces a sentence that means nothing.
• Local number formats. "1,20,000" and "120,000.00" and "Rs 1.2L" are the same amount written three ways.
• Stamps and signatures. A "PAID" stamp over the total turns a clean number into noise.
• Multi-page documents. Page one is the invoice; page two is terms and conditions that OCR happily reads as line items.

Why layout matters more than characters

Modern document models don't read left-to-right and top-to-bottom. They build a spatial representation of the page first where the blocks are, which ones align, which text is inside a box and then extract meaning from structure. A number sitting in the right-hand column under "Amount" is a total. The same number in a paragraph is not.

Character accuracy of 99% still produces a wrong invoice if you extract the wrong 99%.

Practical advice

Benchmark on your own documents, not on a public dataset. A model that scores 97% on English receipts may score 70% on your scanned delivery notes. And always keep a confidence score per field, not per document the total being uncertain matters far more than the PO number being uncertain.

Three-way matching is conceptually simple: the purchase order says what you agreed to buy, the goods receipt note says what actually arrived, and the invoice says what you're being charged. All three should agree before payment.

In practice, they rarely agree, and the differences are usually small enough that a human has to look at every one.

The tolerance question

The single most useful decision you'll make is your tolerance policy. Matching to the cent produces enormous exception queues. A sensible starting point:

• Quantity: exact match required over-delivery is a real problem.
• Unit price: ±1% or LKR 100, whichever is greater.
• Total: must reconcile after tax and rounding.

Handling the exceptions

Roughly 12–20% of invoices will fall outside tolerance. Don't try to eliminate that automate the resolution. When a mismatch is detected, the workflow should attach all three documents side by side, highlight the differing field, and route it to the person who can actually decide.

A good exception takes 30 seconds to resolve. A bad one takes twenty minutes of document hunting.

The result

Teams that automate matching with clear tolerances typically see straight-through processing rates of 80%+ and a dramatic drop in duplicate payments, because the system checks for an existing match before anything is approved.

Payroll is the one process where "mostly right" is unacceptable. Every month, the same calculations run against rules that occasionally change, and the cost of a mistake is a correction filing plus a very uncomfortable conversation.

What makes it hard

• Multiple categories. Permanent, contract, and probationary staff attract different treatment.
• Ceilings and thresholds. Contributions apply up to a limit, and the limit is not always the same across schemes.
• Variable inputs. Overtime, allowances, loans, and no-pay leave all land days before the run.
• Filing formats. Each authority wants its own layout.

Making it boring

The trick is to separate the rules from the run. Statutory rates live in a configuration table that a human updates when the law changes not hardcoded inside the calculation. The monthly run reads current rates, applies them to validated inputs, and produces both the payslips and the filing files from the same numbers.

If your payslip and your EPF return are generated from two different calculations, they will eventually disagree.

Controls worth having

Before anything is released, run three checks: variance against last month (flag any change over 15%), total cost against the approved budget, and a completeness check that every active employee appears exactly once. Those three catch the overwhelming majority of payroll errors before they reach a bank file.

A mid-sized freight forwarder in Colombo came to us with a familiar complaint: the operations team was competent, but permanently behind. Every shipment generated paperwork, and every piece of paperwork generated a phone call.

Where the time went

We spent two weeks shadowing the team before writing a single workflow. The findings:

• 38% of time on data entry between the TMS, email, and customs portals.
• 24% chasing document status by phone and email.
• 19% on exception handling usually a mismatch between a booking and a bill of lading.
• 19% on actual operational judgement.

What went wrong first

The first workflow we shipped automated the entire booking-to-invoice path in one go. It broke within a week. The team had exceptions they'd never verbalised because they'd never had to they just handled them instinctively.

We rolled back, split it into three smaller workflows, and shipped them one at a time with a week of parallel running each. That worked.

The twelve-month result

Nine workflows in production. Roughly 1,400 hours returned to the team annually about 0.8 of a full-time role. Shipment documentation turnaround fell from 6.5 hours to 50 minutes. Overtime dropped by 71%.

The biggest win wasn't speed. It was that the team stopped dreading Monday.

The lesson we keep repeating to clients: automate the smallest useful slice first, run it in parallel, and let the exceptions teach you what the next slice should be.

Every workflow tool is pleasant to use until you need to change a live process. Then you discover the hard question: what happens to the instances already running?

The three bad answers

• Kill them. Users lose work and trust the system less.
• Migrate them. Sounds elegant until the old instance is on a step that no longer exists.
• Block editing. Now nobody can fix anything without a maintenance window.

What we built instead

Workflows are versioned. When you publish an edit, a new version is created and becomes the default for new instances. Instances already running continue on the version they started with, untouched, until they complete.

You can see at a glance how many instances are on each version, and when the last one drains you can archive the old definition.

The escape hatch

Sometimes you do need to move running instances forward for example, when a compliance rule changes and every in-flight approval must use the new wording. For that we added an explicit, opt-in migration with a preview: it shows exactly which instances can move safely and which will be left behind, before you commit.

Editing a live workflow should feel like editing a document, not defusing a bomb.

Versioning is on by default for all workflows, with a full history of who published what and when.

This is the question we get asked most often, and the honest answer is that it depends on your supplier base not on which technique is theoretically better.

The benchmark

We ran both approaches against 50,000 historical invoices spanning 14 recurring layouts, measuring field-level accuracy on invoice number, date, supplier, subtotal, tax, and total.

What we found

• On stable layouts the same 14 formats, month after month fine-tuning won clearly. 98.4% field accuracy versus 94.1% for prompting.
• On new, unseen layouts prompting won. 91.3% versus 76.8%, because the fine-tuned model had never seen anything like them.
• On cost prompting was cheaper to start, fine-tuning cheaper per document at volume.

The deciding factor

Layout drift. If 90% of your invoices come from 15 suppliers, fine-tune. If you onboard new suppliers every week, prompt or better, use a hybrid: a fine-tuned model for the known formats, falling back to a general prompt-based extractor for anything unfamiliar.

Don't choose a technique. Choose a routing rule that picks the right one per document.

What we'd do again

Build the evaluation set before building anything else. 500 labelled invoices from your own archive will tell you more than any benchmark table and it's the only way to know whether a change actually helped.