· Kevin Li · Workflow design · 10 min read

How to Automate Invoice Processing: From Receipt to Approved Bill

Build an invoice workflow from capture to an approved accounting record. A worked three-way match shows why receipt and prior-invoice history matter.

How to automate invoice processing: connect supplier-invoice intake, data capture, validation, matching, approval, and a confirmed accounting-system record. Use OCR or AI to read documents when needed, but let approved purchasing, receiving, and finance records determine whether the bill can proceed.

For a first release, I recommend one recurring invoice class from established suppliers, with payment execution kept outside the workflow. The accepted result is an approved bill recorded correctly—or a specific unresolved invoice assigned to the person who can resolve it.

Start with the invoice below. Its quantity is smaller than the quantity received, yet approving it would exceed the remaining received coverage. That distinction helps identify whether you need better document reading, better system data, or a different approval path.

Start with one invoice the system should hold

This synthetic example concerns supplier invoices in accounts payable, not customer billing or incoming payments. All quantities refer to the same purchase-order line, supplier, legal entity, currency, and unit of measure. There are no returns, credits, taxes, freight, or allowed price or quantity variances.

RecordQuantity and priceMeaning
Purchase order PO4107100 units × $10 = $1,000Authorized purchase
Accepted receipts against that line80 unitsGoods received and accepted so far
Earlier invoices against those receipts60 units × $10 = $600Receipt quantity already consumed by prior invoicing
New invoice INV73030 units × $10 = $300Supplier’s current claim

A check that compares only the new invoice with total receipts sees 30 ≤ 80 and passes. It misses the 60 units already invoiced.

The useful calculation is:

  • Remaining received coverage: 80 − 60 = 20 units, worth $200 at the agreed price.
  • New invoice: 30 units, worth $300.
  • Quantity without received coverage: 30 − 20 = 10 units, worth $100.
  • Cumulative invoiced quantity if this proceeds: 60 + 30 = 90 units, exceeding the 80 received.

For this first cohort, assume finance requires the whole $300 invoice to remain on hold until the discrepancy is resolved. The workflow should retain INV730 and send purchasing or receiving the evidence: PO4107, receipts for 80, prior consumption of 60, and the new request for 30.

The $100 is an unsupported portion under these assumptions—not an observed loss, proven fraud, or automatic write-off. Nor does the $200 supported portion authorize the software to split the bill, change its quantity, or release a partial payment.

Receipt matching is not a new idea: Microsoft’s AP matching documentation distinguishes price matching from three-way matching with selected receipt quantities. Oracle documents quantity-received holds when billed quantity exceeds received quantity beyond configured tolerances. The calculation above is our simplified analysis, not a reproduction of every product’s matching algorithm.

Its practical implication is specific: an extractor that reads all 30 units correctly has done its job. If the automation cannot retrieve prior invoice consumption, a more capable language model does not supply the missing accounting history.

Build six connected steps from receipt to approved bill

The matching example is one decision inside a complete process. Connect the surrounding work so a valid invoice can finish, and a held invoice does not disappear into an inbox.

1. Receive the invoice once and retain its source

Choose the accepted entry point for the first cohort: an AP mailbox, supplier portal, electronic feed, or controlled upload. Preserve the original file and arrival information, then give the case a stable identity.

Recognize repeated deliveries. A forwarded copy of INV730 should not create a second payable simply because it arrived through another channel. File-level similarity can help find copies, but it is not enough: a revised document can have a different file while retaining the same invoice number.

Separate invoices from statements, credit notes, and supporting delivery documents. If a supplier sends several invoices in one PDF, split or identify them deliberately before extraction. Otherwise, a plausible header from one invoice can be paired with another invoice’s lines.

2. Capture the fields your accounting record needs

For INV730, the useful output includes supplier identity, invoice number and date, currency, PO4107, the relevant line, 30 units, $10 per unit, and $300 total. Preserve the source evidence so a reviewer can check a proposed value.

Use machine-readable invoice data or native PDF text where it works. Add OCR for image documents and a document model when layout variation requires interpretation. The invoice extraction comparison covers that choice without making document reading stand in for the whole AP process.

Microsoft’s AI Builder invoice model exposes common invoice fields and confidence values. Its documentation also warns that processing a page range spanning separate invoices can return partial data from both. That is a reason to test the document boundary, not merely the model’s confidence label.

A high-confidence reading of “30” is evidence about extraction. It is not permission to approve 30 units.

3. Resolve the supplier, duplicates, and basic validity

Match the document to an approved supplier in the correct entity. Check invoice identity against pending and posted records, not just the files in today’s queue. Compare plausible duplicate candidates rather than silently deleting a legitimate recurring charge.

Check required values, currency, arithmetic, allowed dates, and record types under finance’s rules. A subtotal or invoice total that does not reconcile needs an explanation before it becomes an approved record.

Keep new suppliers and changes to payment details on their authorized verification path. An invoice’s bank instructions should not overwrite approved master data merely because the extractor read them clearly. Payment execution remains out of scope for this first release.

If these checks fail, show the exact reason and owner. “AI could not process invoice” is not useful when the real problem is that the supplier is inactive or the same bill already exists.

4. Match the claim and prepare the accounting coding

For PO-backed goods, retrieve the purchase order, relevant accepted receipts, prior billed or reserved quantities, and authorized tolerances. In this simplified example, those inputs expose the 10-unit shortage.

The same receipt quantity must not be promised twice. Two invoices evaluated concurrently can each appear to fit if both read an unchanged available quantity. Prefer the accounting system’s supported matching and reservation behavior; test concurrent submissions rather than maintaining an uncoordinated spreadsheet balance beside it.

Keep match evidence separate from coding. Even a covered quantity needs the appropriate account, department, project, tax treatment, and other fields required by your setup. Use approved rules or reviewer decisions; do not ask a model to invent financial policy from a product description.

For INV730, retain the proposed $300 bill with a receipt discrepancy. Do not represent it as approved simply because all required fields were populated.

5. Route the decision to someone who can resolve it

The receiving owner can confirm whether another delivery occurred. Purchasing can investigate an incorrect supplier quantity. Finance decides whether an authorized exception or another treatment is appropriate.

Give that person the source invoice, matched records, discrepancy calculation, and permitted actions. “Approve?” without the prior 60-unit history invites a decision on incomplete evidence.

When the evidence changes, rerun the relevant validation. An email saying “looks fine” should not silently rewrite a receipt or bypass a price mismatch. If your policy permits an override, record who authorized it and what it covers. Use the human-review workflow guide for escalation and queue design rather than adding another generic approval layer here.

6. Confirm the resulting record in the accounting system

Once the invoice meets the approved policy, create or advance the bill through the supported integration. Some systems use a pending or draft invoice before approval; others sequence these actions differently. The required end state is a confirmed record with the correct identity, amounts, approval, and status—not a universal API sequence.

Suppose an additional accepted receipt resolves INV730’s shortage. After the other checks and approval pass, the workflow should confirm a $300 bill for the correct supplier and PO, retain its accounting record ID, and link it to the original invoice. It still should not claim that the supplier has been paid.

If posting times out, look up the attempted result before retrying. An unknown response is not proof that no bill exists. Repeated intake or a repeated integration event should not create a second liability.

Change the inputs before granting more authority

The arithmetic should respond to real changes, not always produce the same “hold” answer. Starting from INV730, change one assumption at a time:

Changed inputRecalculated resultDecision under the example policy
Accepted receipts increase from 80 to 90 units90 − 60 = 30 available; invoice needs 30Quantity coverage passes; finish the other checks
Prior invoice consumption is corrected from 60 to 50 units80 − 50 = 30 availableQuantity coverage passes after the correction is verified
Receipts remain 80, but invoice unit price changes to $1130 × $11 = $330; $30 above the PO price for those unitsBoth quantity coverage and price need resolution

We independently checked these calculations, including the pricing change, using integer cents. They are expected outcomes for stated synthetic inputs, not an executed ERP integration or measured error rate. A legitimate correction requires supporting evidence; changing a number merely to make a test pass is not a resolution.

The hold decision also depends on policy. A business may authorize partial-invoice treatment, agreed tolerances, or an advance-payment arrangement. If so, configure that separate path explicitly. Our whole-invoice hold is a conservative starting choice for ordinary received-goods invoices, not a universal accounting requirement.

Non-PO and service invoices need a different basis. An approved contract, service acceptance, milestone, or cost owner’s authorization may support them without a warehouse receipt. Forcing a consulting invoice through a goods-receipt check creates work rather than control.

Automate the missing step, not the entire technology stack

Use the worked invoice to choose the project:

The document is hard to read, but AP processing already works. Add capture and field review around the existing system. Do not replace functioning approval and posting because one supplier uses an awkward PDF.

The fields are correct, but receipt or prior-invoice history is unavailable. Repair that connection first. INV730 fails for missing business context, not a lack of generative reasoning. If receiving records are not being entered reliably, the first change may be operational rather than technical.

The match is clear, but approvals sit untouched. Improve assignment, evidence, delegation, and escalation. A new extraction service will not make an absent approver available.

Native AP functionality already handles the cohort. Configure it before introducing another platform or custom agent. The native-first implementation guide explains when a durable integration gap justifies custom work.

A broader AP platform can be appropriate when intake, matching, approvals, and supplier communication are genuinely fragmented. Compare it against your actual invoice population and system access, not a demonstration that reads one document well. KelenAI’s invoice processing automation service focuses on that bounded workflow and the handoffs it must complete.

Try the complete path, not just the extraction

Begin with representative invoices from the chosen cohort, with confidential details handled through approved channels. Include a clean invoice that should become an approved bill, INV730’s shortage pattern, a duplicate delivery, an unknown supplier, and a price discrepancy.

For each case, inspect the outcome in the test accounting system. Did the clean bill retain the right supplier, line, value, and approval? Did the shortage reach receiving with its calculation? Did the duplicate stop without losing the original? Did a repeated event or a timeout create an extra record?

Then change the underlying evidence and rerun. Add the legitimate receipt; confirm that the hold can resolve. Introduce a new price discrepancy; confirm that clearing quantity does not clear price. A workflow that can only reject invoices has not demonstrated useful automation.

Our example supplies the calculations and expected decisions, not proof that your integration passes those tests. Use the pilot-to-production roadmap for the broader release process.

Evaluate the business case against the actual bottleneck: capture effort, missing receipt evidence, approval delay, or correction work. Staff time released is not automatically an expense removed. The AI automation ROI guide helps keep those benefits distinct without inventing a universal cost per invoice.

Submit one supplier-invoice path

Describe how invoices arrive, which accounting system holds the bills, and one recurring point where work stops. KelenAI’s free workflow consultation request starts with that context; we review it and follow up if a focused conversation would help.

Please do not submit bank credentials, full account numbers, or confidential supplier records. A description of the workflow is enough to start.

Share:
Back to Insights

Related Posts

View All Posts »