Invoice processing automation should remove re-keying without allowing uncertain data to become an accounting record. The safest design separates five jobs: capture the invoice, extract its fields, validate them, obtain any required approval and then post it. An invoice can be readable enough to capture while still being unsuitable for automatic posting.
Start with the work your accounts team does today. An invoice arrives in the accounts inbox, someone identifies the supplier, enters the invoice number, dates, net, tax and gross totals, looks for a purchase order, asks someone to confirm delivery, selects an account code and creates a bill. Automation can prepare much of that record. Finance should decide which conditions must be true before it can be posted without intervention.
Map the route from accounts inbox to accounting record
Give invoices one controlled entry point, such as a dedicated accounts mailbox or supplier upload portal. Save the original document as it arrives and assign it a unique reference before any extraction begins. This matters when the same invoice is later resent, uploaded through a portal or forwarded by a colleague.
The capture step reads the document and proposes fields: supplier name, invoice number, invoice date, due date, currency, line items, net amount, tax, freight or discount, and gross total. It should also retain the PDF or image beside the proposed accounting record.
Extraction is not validation. A document reader may correctly find a supplier name while confusing an invoice number with a customer reference, or read a tax amount incorrectly from a poor scan. Check that net plus tax, adjusted for stated charges and discounts, reconciles to the gross total. Check dates and currency where they matter. Treat a missing invoice number, a negative amount or a credit note as an explicit route, rather than letting it fall through rules designed for ordinary supplier bills.
Use supported integrations or controlled imports to create a draft in the accounting system, which should remain the system of record. Keep a visible link between the source document, extracted values, changes made by staff, approvals and the final posted transaction. An inbox is not a sufficient audit record.
Match the supplier using approved records, not a similar name
Supplier matching should use the approved supplier record and its identifier, not simply the closest text on the invoice. A trading name, abbreviation or old address can resemble more than one supplier. Where the match is unambiguous, store the supplier ID used by the accounting system. Where it is not, send the invoice to review with the candidate suppliers shown.
Before posting, check for possible duplicates against the supplier, invoice number, amount, date and existing accounting records. Normalise superficial differences first, such as spaces, punctuation and letter case in invoice numbers. However, a near-match should normally be a review flag, not an automatic rejection. Recurring invoices, credit notes and supplier numbering changes can resemble duplicates for legitimate reasons.
Keep duplicate-document detection separate from duplicate-payment prevention. The first stops the same PDF becoming two bills; the second also needs to consider bills and payment status already held in the accounting system.
Invoice Workflow: Capture, Check, Route
Supplier invoice workflow
Use the right path for PO and non-PO invoices
Identify early whether the invoice is linked to a purchase order. For a PO invoice, two-way matching compares the invoice with the PO. Three-way matching adds evidence that goods were received, or that a service was confirmed, where that evidence is relevant. A PO number printed on an invoice is not proof of a match. It must be associated with a real PO and pass the configured checks.
Set matching tolerances as a documented finance and procurement policy, not as a technical default. A small rounding difference may be acceptable for one category of spend, while a price or quantity variance for another needs investigation. Consider price, quantity, tax, freight and discounts separately where they appear. The person who can approve an exception, and the explanation they must provide, should be clear.
Legitimate non-PO invoices need their own visible route. A utility bill, recurring software subscription or professional-services invoice may have no PO or goods receipt to match. That does not make it invalid. It needs the appropriate account coding and approval based on your policy, with the document and context available to the approver. Monitor suppliers that routinely bypass purchasing controls, as this may point to a purchasing-process issue rather than an invoice-processing failure.
Define auto-post rules and make everything else an owned exception
Automatically post only invoices that meet clear supplier, total, tax and matching rules; route unfamiliar suppliers, duplicates, missing references and mismatches to a visible exception queue.
For example, an invoice from an established office-supplies supplier may be eligible for auto-posting when the supplier ID is certain, the invoice number is new, the totals reconcile, a valid PO is found and the invoice passes the agreed match rules. An invoice from the same supplier with an unexplained freight line or quantity difference should become a draft or exception, even if the document was extracted with high confidence.
The queue is an operating process, not a holding area. Each exception needs a reason, an owner, the original document, extracted values, linked PO or receipt information where available, and a deadline. Useful reason codes include unknown or ambiguous supplier, suspected duplicate, invoice number missing, totals do not reconcile, PO missing, PO not found, price variance, quantity or receipt variance, tax issue, approval required and integration failure.
Route each class to the person able to resolve it. Finance can correct an account code or investigate a duplicate. Purchasing may need to clarify a PO. The person receiving goods or the service owner may need to confirm receipt. Escalate items approaching their payment due date, and report exception age, reason and supplier so recurring failures lead to better supplier records, POs or rules rather than repeated manual work.
Invoice Posting: Automate, Review or Keep Human
Prepare the data and roll out in controlled stages
Before building rules, inspect a sample of invoices and the records they should join. Look for duplicate supplier records, missing supplier identifiers, inconsistent PO references, unreliable receipt records, recurring invoices with no agreed approval route and common formats that defeat extraction. These are process and data issues that automation will expose, not solve by itself.
Begin with stable, high-volume suppliers and well-formed PO invoices. Create drafts first, compare the proposed record with what finance would have entered, and review a sample of auto-posted invoices during the rollout. Track false positives, unresolved exception age and corrections made after posting. Broaden the rules only when the evidence shows that a particular invoice type is consistently handled correctly.
Keep permissions separate as well. Changing supplier bank details is a related accounts-payable control and should not be available merely because someone can enter or approve an invoice. Protect mailbox access and stored documents, and make changes to records traceable.
If the current process involves staff copying between an inbox, spreadsheets, purchase orders and accounting software, invoice workflow integration should start by mapping those hand-offs and the decisions behind them. The useful outcome is a controlled route for routine invoices and clear work for the exceptions, rather than a faster way to post bad data.
Map the invoices your team still has to type in
Show ZappFlow the accounts inbox, accounting system and the checks your team performs before entering an invoice. We can identify which invoices can be processed automatically and which need a controlled review step.