The buyer gets a PDF copy of an invoice the supplier already submitted electronically, and forwards it to AP. AP now has both. If each channel creates its own draft, the team reviews the same obligation twice, and if both drafts post, you pay it twice.
The first requirement for invoice processing automation is that every bill, whatever channel it arrives through, becomes exactly one traceable record in the ledger. Capture speed comes second.
The four steps and what each must prove
| Step | What the tool can prepare | What to verify |
|---|---|---|
| Intake | One record per obligation, with every source attached | No existing draft or posted bill for the same supplier, entity, and invoice number |
| Capture | Supplier, reference, dates, lines, and totals | Fields agree with the original, and uncertain fields are flagged |
| Coding and matching | Entity, account, department, and links to the PO and receipt | The approved price and the quantity actually received |
| Posting | The approved bill with its accounting details | Posted once, to the intended entity and period |
Keep invoice approval separate from payment release throughout. A bill that passed matching can be ready for approval without being authorized for payment.
Intake: get each bill into the queue once
Record what arrived
For every document or message, save the original file, arrival time, channel, supplier, buying entity, and invoice reference. Electronic invoices often arrive with structured fields already. X12, for example, identifies 810 as its invoice transaction set (X12’s 810 invoice implementation guide). Check which fields your trading partner actually supplies before choosing how to map them. A PDF needs extraction or manual entry, but both paths should produce a draft AP can trace back to its source.
Work a shared AP inbox
A supplier forwards last week’s bill and asks when it will be paid. That second email belongs with the first invoice record, not in a new payable.
| What arrives in the inbox | What the reviewer needs |
|---|---|
| One bill in a readable attachment | Original email and file, supplier reference, amount, proposed PO |
| Several invoices in one email | A separate record for each bill, linked to the shared message |
| Repeat or revised invoice | Both versions, and any existing bill or payment |
| No readable bill, or missing data | The original message and a specific request for the missing item |
| Statement listing several invoices | The bills it lists and any missing invoice documents to request |
If an email also asks to change payment instructions, route that request through independent vendor verification. Do not use new bank details that arrive on, or with, a bill.
Oracle’s NetSuite Bill Capture documentation describes email and upload options and a duplicate reference warning when a corresponding bill has already been created (Oracle’s vendor bill upload guide). Test a repeat submission both before the first copy posts and after it, because those are different checks.
Tell copies from new work
Before creating a draft, compare entity, supplier, invoice number, amount, and document type against existing drafts and posted bills. Similar invoice numbers can belong to different suppliers or entities. A changed amount on the same number can be a correction that needs its own review.
| What arrives | What AP should see |
|---|---|
| PDF copy of an electronic invoice | Both source references attached to one review record |
| Corrected amount on an approved invoice | Old and new amounts, the prior approval, and whether the bill posted |
| Credit against a posted invoice | The original bill and the amount the credit is meant to reduce |
If the reviewer cannot tell which case applies, keep the item open with a stated reason and ask the supplier or buyer for the missing evidence.
Capture: OCR versus AI-assisted extraction
Template OCR reads text from fixed positions. AI-assisted capture reads the document more flexibly and can propose values from context. Either can extract every number on a PDF and still put the wrong one in the total field, so compare tools on the fields AP needs and the decisions that follow, using a batch your team has already reviewed so you have a correct answer for each.
| Give each tool | What to check |
|---|---|
| A scan with a faint invoice reference | Whether it flags uncertainty and points the reviewer to the source |
| An invoice with tax and several subtotals | Whether it selects the right total and currency |
| A bill with a handwritten PO reference | Whether it finds the intended order or asks for review |
| A revised bill with the same reference | Whether it shows the prior bill and lets AP choose the right version |
| A credit printed on a separate page | Whether the lines still add up to the selected total |
Score extraction first, then count the corrections needed before each bill is ready for approval. A tool that reads the total correctly still needs a way to explain a missing receipt or a conflicting vendor record. Test duplicate handling separately from extraction so you can see what the capture tool contributes and what the ERP contributes.
Coding: show where each value came from
Coding suggestions usually come from one of three places: the PO, a vendor default, or the history of past bills. Only the first is evidence about this bill. When a supplier bills more than one entity, a tool that reuses last month’s coding will pick the wrong company eventually.
Ask the tool to label each field as read from the document, taken from a purchasing record, or inferred from history. Have AP review inferred values on any bill above your review threshold, and save every correction with the invoice version it applies to.
Matching: hand off with the evidence attached
Microsoft’s Dynamics 365 Finance documentation illustrates three-way matching: invoice unit price compared with the PO, and invoice quantity compared with matched product receipts (Microsoft’s invoice matching overview). Microsoft also documents that Dynamics 365 Finance can automatically match posted product receipts and submit imported invoices to workflow under configured conditions (Microsoft’s invoice workflow documentation). When evaluating a separate tool, ask which steps your ERP already performs and which ones the tool adds.
Follow one delivery through three documents: the original invoice, a forwarded copy with a reformatted reference, and a bill for more units than the warehouse received. The first should carry its PO and receipt evidence. The copy should point AP to the earlier record. The third should leave the unmatched quantity visible for receiving. The three-way matching guide covers tolerances and partial receipts in depth.
Posting once: keep a batch log
The most dangerous moment in invoice processing is a write that times out. The ERP may have saved the bill, or it may not. Someone retries, and now there might be two.
Keep a batch log with one row per input document and a column for the resulting bill ID. After any retry, compare that column with the ledger. Investigate every input with more than one bill ID and every posted bill with no approved input. Record held and rejected invoices with their reasons.
Worked example: when the batch total lies (illustrative)
A batch of 12 approved invoices totals $48,300. After an interrupted import and a retry, the ledger shows 12 new bills totaling $48,300. Count and total agree.
The batch log shows what happened:
| Input | Supplier | Amount | Bill IDs found |
|---|---|---|---|
| #4 | Supplier B | $1,850 | Two |
| #7 | Supplier G | $1,850 | None |
| All others (10) | Various | $44,600 | One each |
$1,850 + $1,850 + $44,600 = $48,300 on the input side. On the ledger side, two bills for #4 plus ten others is also 12 bills, and $1,850 × 2 + $44,600 = $48,300. Supplier B is set up to be paid twice and Supplier G will not be paid at all. Only the row-level log catches it. Void the duplicate for #4 before the next payment run and post #7.
Measure on a real batch before you buy
Take a week of invoices and sort them by what AP did with them. Some were entered and approved quickly. Others waited for a receipt, went back for correction, or never posted. Compare each group separately so a tool that speeds up entry does not get credit for time spent waiting on another team.
- Record the intake channel and invoice type, including non-PO bills and credits.
- Track staff handling time separately from time waiting for evidence or approval.
- Count corrected fields, reopened invoices, and posting failures.
- Run the same mix through the proposed workflow and compare against the approved records.
If missing receipts drive most of the wait, check whether the tool gets the request to receiving with enough detail to act. If manual entry drives most of the work, count the fields AP still corrects. Include review and support time when comparing pilot results with a quote; the AP pricing and ROI guide shows how.
What goes wrong
- Each channel creates its own draft and nobody checks across channels.
- A corrected invoice replaces the original silently, and the approval still points to the old amount. The invoice approval workflows guide covers reapproval rules.
- A rejected attachment disappears instead of staying visible with a reason.
- Similar invoice numbers from two suppliers are treated as duplicates, or real duplicates with different spacing are not. The duplicate payments guide covers matching logic.
- A field-level accuracy score looks good while whole bills fail on one wrong entity.
For how this fits the rest of the AP process, see the AP automation guide.
Test batch for your next evaluation
| Case | Expected result |
|---|---|
| PDF copy of an EDI invoice | Attached to the existing record, no second draft |
| Two invoices in one email | Two records, both linked to the message |
| Unreadable attachment | Stays visible with a request to the supplier |
| Invoice without a PO number | Original visible, specific question routed to AP |
| Receipt arrives after the bill | Record shows why it stopped and how the receipt changes the match |
| Amount changes after approval | Follows your reapproval policy and keeps the prior version |
| ERP times out on posting | Existing-bill check before retry, one bill in the ledger |
| Bank-detail change in the email | Routed to vendor verification, not applied |