Challenge
Units of measure differ: the PO says boxes, the invoice says each.
Agnotic approach
Unit conversions are stored per item and supplier, and matching runs on the converted quantity.
Invoice Processing Automation
Automated invoice processing software
Accounts payable teams key invoices from PDFs, chase approvers by email and find duplicates only after they are paid. Agnotic Technologies builds invoice processing automation that takes invoices from every channel, matches them to purchase orders and receipts, routes approvals and posts clean entries to your ERP.
Email, EDI and e-invoicesTwo and three way matchingApproval routingDuplicate and bank change checks
Trusted by global innovators
Accounts payable
What is automated invoice processing?
Automated invoice processing is accounts payable software that receives supplier invoices from email, EDI and e-invoice networks, matches each one to its purchase order and goods receipt, routes exceptions and approvals, and posts the result to the ERP. Agnotic Technologies builds invoice processing automation for finance teams, around your own ERP and approval rules.
Reading fields off a PDF is only the first step, and our document intelligence systems page covers that capture layer. This page is about what happens next: the matching, tolerances, approvals and vendor checks that decide whether an invoice should be paid.
The aim is not to touch every invoice faster. It is to let clean invoices pass without a person, and to put each exception in front of the one person who can fix it.
Intake
Which invoice formats can the system take in?
Every channel ends in the same invoice record, so matching and approvals do not depend on how an invoice arrived.
| Code | Name | Typical use |
|---|---|---|
| PDF by email | Supplier invoices sent to an AP mailbox | The most common channel. Needs extraction and a check of low-confidence fields. |
| Scan | Paper invoices scanned in the mailroom | Extraction as for PDFs, with the scan image kept as the original. |
| X12 810 | EDI invoice | Structured lines from suppliers already trading by EDI, mapped straight to PO lines. |
| Peppol BIS Billing 3.0 | UBL e-invoice over the Peppol network | Structured invoices from suppliers in countries that use Peppol, received through an access point. |
| cXML | InvoiceDetailRequest from a procurement network or punchout supplier | Structured lines tied to the cXML order they bill. |
| Supplier portal | Invoice keyed or uploaded by the supplier | Validation runs while the supplier enters it, so errors are fixed at the source. |
Invoice flow
How does an invoice move from inbox to ERP?
One supplier invoice, from arrival to a scheduled payment.
Receive
The invoice arrives by email, portal, X12 810 or a Peppol access point, and lands in one queue with its original file kept.
Capture
Structured invoices are read directly. PDFs and scans go through extraction, and low-confidence fields go to a person.
Validate
Supplier, tax ID, currency, totals and line arithmetic are checked, and the duplicate rules run.
Match
Lines match to the purchase order and, for goods, to the receipt, inside tolerances set per supplier and category.
Approve
Non-PO invoices, and matched invoices above a set amount, go to the budget owner under your delegation of authority.
Post
The approved invoice posts to the ERP with GL coding, tax and due date, ready for the payment run.
Exception table
Which invoice exceptions does the system catch?
The exception table each build starts from. Your controller sets the tolerances, and the system applies them the same way every time.
| Exception | Rule that catches it | Who resolves it | What the system records |
|---|---|---|---|
| Price variance | Unit price differs from the PO price by more than the tolerance for that supplier or category | Buyer who owns the PO | Both prices, the tolerance applied and the buyer's decision |
| Quantity variance | Invoiced quantity is more than the quantity received so far | Receiver or buyer | Received quantity at that time, and whether the invoice was held or short paid |
| No receipt | The PO needs a goods receipt and none is posted yet | Requester or warehouse | The hold reason and the date the receipt was finally posted |
| Duplicate invoice | Same supplier and invoice number, or same amount and date with a near-match number | AP specialist | The invoice it collided with and the outcome |
| Vendor bank detail change | Remit-to account differs from the verified account on the vendor record | Vendor master team, not AP | The call-back confirmation, the approver and a hold on the first payment |
| Missing PO | No PO quoted, or a closed or unknown PO number | Requester named on the invoice, or AP | Whether a PO was raised after the fact or the invoice was approved as non-PO spend |
Every exception carries a reason code, so the AP team can see which suppliers and rules cause most of the work and fix them at the source.
Matching
Where does three-way matching go wrong?
Most matching failures are data problems, not fraud. These are the ones we design for.
Challenge
Freight, surcharges and handling fees appear as lines with no PO line.
Agnotic approach
Charge lines get their own tolerance and GL coding rules instead of failing the whole invoice.
Challenge
The goods arrived, but nobody has posted the receipt yet.
Agnotic approach
The invoice waits on a timed hold and reminds the receiver, rather than going straight to an exception queue.
Challenge
One invoice covers several partial deliveries.
Agnotic approach
Matching works at line and receipt level, so part of an invoice can match while the rest waits.
Challenge
Rounding on unit prices leaves small differences.
Agnotic approach
A small absolute tolerance sits beside the percentage tolerance, so cents do not stop an invoice.
Approvals
How are invoice approvals routed?
Approval rules come from your delegation of authority, kept in one place that finance maintains.
- Matched PO invoices inside tolerance post without a second approval, because the PO was already approved
- Non-PO invoices go to the cost center owner, then up the chain by amount
- Thresholds by amount, entity and spend category, set by finance rather than in code
- Delegation while an approver is away, with an end date and a record of who acted
- Reminders and escalation when an invoice waits too long close to its due date
- Approve or reject from email or phone, with the invoice image attached
Who it is for
Who do we build invoice automation for?
Finance teams where invoice volume has outgrown keying and email approvals.
Mid-size and enterprise AP teams
Teams processing invoices from many suppliers across several entities and ERPs.
Distributors and manufacturers
PO-backed purchasing with goods receipts, where three-way matching decides most invoices.
Multi-location service businesses
Clinics, restaurants or property portfolios with many non-PO invoices and local approvers.
Shared service centers
Central AP teams working for many business units, each with its own approval rules.
What do we build into invoice processing automation?
Modules for the AP workflow, from the mailbox to the ERP.
Multi-channel intake
Email, scans, X12 810, Peppol and cXML invoices in one queue, with the original file kept.
Capture and review
Extraction for PDFs and scans, with a review screen for low-confidence fields.
Matching engine
Two and three way matching at line level, with tolerances per supplier, category and charge type.
Vendor controls
Duplicate detection, verified bank details and tax ID checks before an invoice can be paid.
Approval workflow
Routing by amount, cost center and delegation of authority, with reminders and escalation.
Exception queues
Each exception type routed to the team that can fix it, with a reason code on every decision.
ERP posting
Approved invoices posted with GL coding, tax and due date through the ERP's API.
AP reporting
Invoices by status, age and exception type, and waiting time by approver.
Scope
What changes the size of an invoice automation build?
No price list: we size the build on the scoping call from these drivers.
Invoice channels
Which of email, paper, EDI, Peppol and a supplier portal you need on day one.
ERPs and entities
Which ERPs receive postings, and how many legal entities and charts of accounts.
Matching rules
Two-way, three-way or both, and how many tolerance rules by supplier and category.
Approval structure
The depth of your delegation of authority and how often it changes.
Vendor master clean-up
Whether vendor records, bank details and tax IDs need cleaning before go-live.
Month-end peaks
Invoice counts at month end, when queues and posting must keep up.
Facts and sources
Facts behind invoice processing automation
The e-invoice, EDI, tax ID and payment fraud rules behind the intake formats and vendor controls, each linked to its primary source.
Peppol BIS Billing 3.0 is a Core Invoice Usage Specification (CIUS) of the European e-invoicing standard EN 16931, so any invoice that complies with it also complies with EN 16931. Its syntax is the UBL Invoice and Credit Note.
Source: Peppol BIS Billing 3.0 (OpenPeppol)The ASC X12 810 Invoice transaction set sets the format and data contents of an invoice in an EDI environment, for billing the goods and services provided.
Source: ASC X12, Transaction Sets (810)The IRS TIN Matching service lets payers and their authorized agents that file information returns check payee name and taxpayer identification number combinations before filing, interactively or in bulk.
Source: IRS, Taxpayer Identification Number (TIN) MatchingNacha Operating Rules define False Pretenses as inducing a payment by misrepresenting a person's identity, their authority to act for another person, or the ownership of the account to be credited. Nacha says the definition covers business email compromise and vendor impersonation.
Source: Nacha, Risk Management Topics: Fraud Monitoring Phase 1
Formats and rules
Which formats and rules does invoice automation follow?
X12 810Peppol BIS Billing 3.0EN 16931UBL 2.1cXMLIRS TIN Matching
Engagement
How does an invoice automation engagement work?
We start from last month's real invoices, not from a demo.
1.
Scoping call
We go through your invoice channels, ERP, approval matrix and a sample of last month's real exceptions.
Scope2.
First release on one entity
Intake, matching, approvals and ERP posting for one entity and its main channels, tested on real invoices.
Build3.
More entities and channels
Further entities, EDI and Peppol suppliers, vendor controls and support after launch.
ScaleFrequently Asked Questions
Capture turns a PDF into fields. Invoice processing automation decides what to do with those fields: match them to the PO and receipt, apply tolerances, route approvals, check for duplicates and post to the ERP. We build capture as one step, or connect the capture tool you already use.
Two-way matching compares the invoice with the purchase order. Three-way matching also compares it with the goods receipt, so you pay only for what arrived. Services and subscriptions usually use two-way matching; physical goods usually use three-way.
Yes. It checks supplier and invoice number, then near matches such as the same amount and date with a slightly different number, across every channel. A suspected duplicate is held and shown side by side with the invoice it collided with.
Bank details live on the vendor record, not on the invoice. A remit-to account that differs from the verified one holds the invoice, and a change needs a call-back to a known contact and a second approver before any payment goes to the new account.
We read POs, receipts and vendors from the ERP and post invoices through its API or integration tools. During scoping we confirm what your ERP exposes, including any custom fields your GL coding depends on.
Yes. Peppol invoices arrive through an access point as UBL documents and skip extraction entirely, which removes keying errors for those suppliers.
It schedules approved invoices for the ERP's payment run. Payment files, bank connections and payment release controls are covered on our treasury management software page.