AI for Data Entry: The Hard Half Is Writing, Not Reading

Somebody in your organisation has two windows open. On the left, a supplier PDF, a broker email, a scanned form or a portal that will not export. On the right, the ERP, the CRM, the claims system or the HR platform. They read a value on the left and type it on the right, several hundred times a week.

Nobody puts this on a strategy slide. It still consumes more headcount than most of the things that do, and it is where the errors that surface three months later as a wrong invoice or a duplicate record are created.

AI can take a large share of this work. But the part vendors demo is the easy part, and the part that decides whether a deployment survives your systems is almost never shown.

Extraction is the easy half

Pulling a field out of a document is close to solved for the common cases. A modern model reads an invoice, a bill of lading, a bank statement or a medical form and returns structured fields without a template, and it keeps working when the layout changes. That capability is real and available.

Then you have to write it somewhere, and everything gets harder.

Your ERP will not accept a vendor record without a tax classification and a payment term code from a controlled list. Your claims system requires a loss date that cannot precede policy inception. Half the fields on the screen are not on the document at all: they are derived from policy, from the requester, from what similar records looked like.

So the real question is not "can it read the number". It is:

• Which of the twenty cost centres is right for this line, given who raised it
• Does this currency and payment term combination even exist in the master data
• What happens downstream if this posts wrong, and how long before anyone notices
• Is there a clean write path at all, or does this system only accept keystrokes

An agent that stops at extraction has automated the enjoyable tenth and left the operator the rest. The value sits in the write, the validation and the exception handling.

Master data and the duplicate problem

The most damaging thing an entry agent can do is create records that should not exist.

Customer, vendor, product and employee masters accumulate duplicates because the same entity arrives through different channels spelled differently. Acme Ltd, ACME Limited, Acme Ltd. at a slightly different address. A human creating the twentieth vendor this week does a half hearted search, finds nothing, and creates a new one. An agent does the same at machine speed, and duplicates are expensive to unwind once transactions hang off both.

The design that works inverts the default. The agent's first job on any master data request is to prove the record does not already exist, using fuzzy matching across name, registration number, tax ID, bank details and address rather than exact comparison. Creation is the last resort. Anything with a near match goes to a human with both candidates side by side.

Give an agent broad authority over transactional entry and narrow authority over master data creation. Transactions are correctable; a polluted vendor master is not, cheaply.

Cross system reconciliation and swivel chair work

A large share of rekeying exists only because two systems that should agree do not talk. The order lives in the CRM, the fulfilment record in the warehouse system, the invoice in the ERP. Someone reconciles by eye and retypes what is missing.

Agents handle this well because the comparison is semantic rather than exact. Line descriptions differ, units of measure differ, one system splits a shipment the other treats as one. An agent can hold both records, explain what matches and what does not, correct the side that is demonstrably stale, and escalate genuine disagreements as a short exception list.

Then there is the portal with no API: government filing systems, carrier portals, ageing applications behind a Citrix session. Here the agent operates the interface the way a person does, reading the screen and deciding what to do next rather than replaying recorded coordinates. This works, but it deserves plain language: it is the least reliable channel you have. Reserve it for systems with no alternative and expect to maintain it.

Confidence thresholds: post it or queue it

Every field carries a confidence, and every record needs a decision: post straight through, or hold for review.

The mistake is one global threshold. Confidence should be weighted by consequence. A misread description on a low value stationery order is a nuisance. A wrong bank account, a wrong dosage or a wrong loss reserve is a different category of event.

A workable policy has three tiers. High confidence on low consequence fields posts automatically. Anything touching money movement, identity, master data creation or a regulated field goes to a human regardless of confidence. Everything in between queues, with proposed values pre-filled so the reviewer confirms or corrects rather than keys from scratch.

Start conservative. A deployment where humans review every record still removes most of the labour, because reviewing a filled form is far faster than filling one.

The audit trail nobody asks for until they do

For every field written, you want a record of where the value came from: which document, which page, which system lookup, which precedent, which rule. For every human correction, what changed and who changed it.

This is not compliance theatre, it is operating instrumentation. When a controller asks in November why a batch of records was coded to the wrong entity in August, the trail is the difference between a ten minute answer and a week of reconstruction. It is also the raw material for improvement: the fields humans correct most often show you where the agent is weak.

Build it before go live. The first time you need the trail is the worst time to find it absent.

What RPA got wrong, and what it got right

Most large organisations already tried this with robotic process automation, and most have a graveyard of bots.

RPA scripts are literal. They click fixed positions and match exact strings, so a redesigned page, a new mandatory field or a slower load breaks them. They also fail loudly, which is their best property: a broken bot stops and someone fixes it.

Agents that read intent survive layout changes, handle documents that vary, and cope with cases nobody scripted. That is a real advance. But they fail differently. An agent that cannot find a field may infer a plausible one. It does not stop. It proceeds, confidently, and writes something wrong into a live system.

So agents need guardrails RPA never needed: validation against the target system before writing, thresholds tied to consequence, human review on high impact fields, reversibility where the system allows it, and sampling of straight through records long after they look reliable. The flexibility that makes agents better is what makes ungoverned agents worse.

Measuring it honestly

"Time saved" is the metric of choice for people who do not want to be measured. It is modelled, not observed. Use numbers your finance team can verify.

Straight through rate. The share of records posted with no human touch. Report it per document type and per system, because a blended average hides the failing categories.

Correction rate. Of the records a human reviewed, how many needed a change, and to which fields. This is the honest accuracy measure.

Downstream defect rate. Records that posted cleanly and turned out to be wrong later. Harder to capture, and the most important number you have.

Cost per record, fully loaded. Inference, review labour, exception handling and maintenance, against your verified manual baseline. Capture the baseline first, because nobody can reconstruct it afterwards.

Cycle time from arrival to posted. Often the benefit the business feels first.

Where AI fails here

Poor source material still defeats it. A faxed form photocopied twice, a scan with the corner cut off, a table spanning a page break with no repeated header. Extraction degrades and the correct behaviour is to route to a person, not to guess.

Handwriting is unreliable at the level of the individual character. Printed capitals in ruled boxes are workable. Cursive annotations in a margin, a European seven, an ambiguous one in a quantity field: these need human eyes, and a system that pretends otherwise posts wrong numbers confidently.

Ambiguous source of truth is a business problem the technology cannot resolve. When the order says one address and the CRM says another and nobody has decided which wins, the agent cannot decide either. Automation exposes the ambiguity rather than fixing it.

Silent errors are worse than obvious ones. A bot that crashes gets fixed on Monday. An agent quietly writing the wrong cost centre for five weeks produces a reconciliation problem, a restated report and a loss of trust that takes far longer to repair.

Systems with no clean write path stay partly manual. Some applications have no API, no reliable interface layer and no supported bulk import. You can drive the screen, but you are accepting fragility, and you should say so when you scope the work rather than after it breaks.

Undocumented policy stalls more deployments than model quality does. If your coding conventions, tolerance rules and mandatory field logic live only in the heads of two long serving people, they have to be written down first, and that is where the project time goes.

And the asymmetry underneath all of it: a wrong record posted confidently costs more than a record left in a queue. Queues are visible and they get worked. Bad data that posted cleanly propagates into reports, payments and decisions, and you pay for it later with interest. Design for that and accept a lower straight through rate than the demo promised.

Where to start

Pick one document type flowing into one system. Measure the manual baseline honestly. Run the agent into a review queue where a human sees everything, so risk during the learning period is near zero while the labour saving is immediate. Then widen straight through processing where the evidence supports it.

Describe your rekeying process to Adopt AI Partners and we will tell you plainly what is automatable now, what is not, and where we would start.