Invoice capture and coding
Supplier invoices read, coded and routed for approval without anyone retyping them — and the ones that genuinely need a human raised as exceptions rather than buried in the pile.
What the manual version actually costs
Count the invoices your team processes in a month. For each one, somebody opens an email or a PDF, reads a supplier name, finds the matching record, types or checks a net value, a VAT value and a date, chooses a nominal code, decides whether it needs a purchase order behind it, and forwards it to whoever is allowed to approve it.
None of that is a decision your finance team was hired to make. It is transcription with a small amount of pattern-matching on top, and pattern-matching is precisely what a rule set does without getting bored on a Friday afternoon.
What replaces it
- Invoices arrive by any route you already use — a dedicated mailbox, a supplier portal, a scanned batch, a capture tool you already pay for — and are read once.
- Supplier is identified against your ledger, not against a fuzzy name match alone, so “ABC Ltd” and “A B C Limited” do not become two accounts.
- Coding is applied from the rules your team is already applying in their heads — by supplier, by cost category, by entity, by whatever your chart of accounts actually keys on.
- VAT treatment is proposed with the reason visible, and anything unusual — reverse charge, mixed rates, a non-recoverable category — is flagged rather than assumed.
- Routing follows your approval matrix, including the escalation when an approver does not respond.
- Everything that does not fit becomes a short exception queue with the reason attached.
The control question
When a person keys an invoice, they are doing something they will not mention if you ask them to describe their job: they are glancing at it. A value that looks wrong for that supplier, a duplicate they half-remember from last week, a bank detail that has changed. That glance is a control, and it is the single most common one to lose in an accounts payable automation.
So it gets rebuilt explicitly. Duplicate detection on value, date and reference. Variance checks against the supplier’s own history. Bank detail changes treated as an event that requires verification, not a field update. The glance becomes a rule, and unlike the glance it does not depend on who is in the office.
Where this sits in a plan. Accounts payable is usually the highest volume rule-driven process in a finance function, which makes it the most common first build. It is not automatically the right one for you — that depends on your volumes and where your exceptions actually cluster, which is what the Review establishes before anything is built.
Common questions
We already use a capture tool. Is this the same thing?
Capture tools read the document. They rarely finish the job — somebody still checks the read, picks the account code, decides the VAT treatment, and routes it to whoever should approve it. Capture is the first ten per cent of accounts payable. The coding, routing and exception handling is the part that still eats the day.
How does it handle an invoice it has not seen before?
It should not guess. A new supplier, an unfamiliar line description or a value outside the usual range becomes an exception with a reason attached, and a person decides. The aim is to shrink the pile a person looks at, not to hide the ones that need looking at.
What happens to approval limits?
They are written into the routing rather than remembered by whoever happens to be forwarding the email. That is usually a strengthening: an authority matrix that lives in the process is enforceable and auditable in a way that one living in an inbox is not.
See it against your own process
The quickest way to know whether this is worth doing is to walk one of your own processes through it. That is what the Finance Automation Review is —one week, ending in a ranked build plan.
How the Review worksBook a call
A first call needs nothing prepared and no system access. We reply within one working day.