Monday morning in accounts payable. One hundred invoices arrived by email, twenty came as scanned paper, and five came as an XML file nobody knows how to open.
There is a fix for this everyday chaos. Intelligent processing of purchase invoices combines OCR, artificial intelligence, and ERP integration, and the technology is already mature and more accessible than it looks.
In this guide you'll see the three families of solutions, how to choose based on your ERP, and how to measure whether it works, because that's where the game is decided.
Why purchase invoices are still a headache
An invoice looks simple, but it hides enormous complexity. Every vendor uses its own layout, its own way of naming taxes, and its own line order.
Then come the formats. A system-generated PDF, a photo taken with a phone, a low-resolution paper scan, and an e-invoice with a digital signature all coexist.
The result is that someone ends up typing data by hand into the ERP, invoice by invoice. It's slow and prone to errors that cost money.
The errors everyone knows
Paying the same invoice two times because it arrived through two different channels.
Entering a total with a shifted digit.
Accepting a bank account change without verifying it, fraud's favorite door.
Accounts payable automation attacks all of these points at once. In industries with thousands of vendors, such as wholesale distribution or consumer goods, the difference is measured in weeks of work per month.
OCR, IDP, and AI: what each technology does, explained simply
Before comparing products, it helps to separate three layers that the market tends to mix up.
OCR: from pixels to letters
OCR (optical character recognition) is the oldest layer. It takes an image or a scanned PDF and turns it into text a computer can read.
But OCR understands nothing. It only knows that the page says "Total" and, somewhere else, "12,500.00".
IDP: understanding what each piece of data is
Intelligent document processing (IDP) adds the understanding layer. It recognizes that the document is an invoice and not a credit note, and it finds the number, the date, the vendor, the taxes, and every detail line.
Modern platforms do this without fixed templates. They learn from the corrections people make.
AI agents: deciding what to do with the information
The newest layer is AI agents, which act on the extracted data. They match the invoice against the purchase order (PO), detect duplicates, propose the ledger account, and decide whether the document is posted automatically or needs human review.
It's the difference between reading and resolving. To go deeper into that logic, take a look at our page on AI agents for companies.
The three families of solutions for automating accounts payable
The market falls into three well-defined groups, each with an ideal company profile.
SaaS accounts payable suites
These are platforms that cover the full cycle: capture, extraction, validation, matching against purchase orders, approvals, and posting to the ERP. They already come with connectors for the most common systems.
Their big advantage is implementation speed and their big drawback is dependency, because you adopt someone else's workflow and migrating to another vendor hurts. If you only want to read an invoice and get a JSON back, it's usually too much.
IDP and hybrid platforms
This group includes tools that treat the invoice as just another document type. They work well when the ERP is homegrown, when there are legacy systems without an API, or when on-premise deployment is required.
Some combine IDP with RPA, robots that operate the screen the way a person would. It's useful when there's no other option, but interface-based automation is fragile and expensive to maintain.
Open source alternatives
There are very solid free tools for OCR and rule-based extraction. They appeal for their control, privacy, and lack of per-document licensing, but they are not an accounts payable system.
Everything else has to be built: tax validations, matching against purchase orders, human review, ERP integration, and security. The most common mistake is counting only the cost of installing the OCR engine, when the real cost is in the months of development that come after.
How to choose based on the ERP you already have
ERP integration matters more than one or two points of extraction accuracy. That's why it makes sense to start the selection with the system already running in the company.
Large enterprise ERPs
If your company runs an enterprise-scale ERP, such as SAP, Oracle Fusion, or JD Edwards, what matters is syncing master data, processing e-invoices, and doing two- or three-way matching against purchase orders and receipts. That's where enterprise suites have the home-field advantage.
We work with this kind of architecture every day as an Oracle partner. The lesson is always the same: the connector matters as much as the reading engine.
Mid-market ERPs
For mid-sized companies with systems such as Dynamics or NetSuite, the range of options is wider. If you make international payments to vendors, look at solutions that go all the way to payment and reconciliation.
Homegrown, vertical, or Salesforce-native ERP
This scenario calls for more care. Don't choose based on the number of published connectors, because none of them will fit a custom-built system.
What you need to evaluate is the quality of the API:
Webhooks, so the system notifies you on its own when there is news.
Idempotency, meaning that resending the same request doesn't duplicate anything.
Export of the original documents.
Extensible data schema.
SFTP as a backup channel.
For an ERP built natively on the market-leading CRM platform, the best option is usually a decoupled IDP layer that delivers clean data through an API. With that approach we built Arconte, an agent that reads, validates and structures documents, and leaves posting to the system of record each company already has.
Our section for Salesforce developers explains how that integration fits into your technical team.
The "98% accuracy" trap
Every vendor publishes an accuracy percentage, and almost none of them is comparable to a competitor's.
One measures accuracy per extracted field, and another measures the percentage of invoices processed without human intervention (what's called touchless). A third measures only system-generated PDFs, where OCR doesn't even do any work.
A solution can get 98% of fields right and still force you to review 40% of documents, because every invoice has a different error.
The only figure that matters is the one you get on your own invoices, with your real suppliers and formats. Everything else is marketing.
Structured e-invoices: don't use OCR where it isn't needed
A common design mistake is converting XML e-invoices to PDF and then running OCR on them. It's like translating a text into Chinese to get back to English: you lose information and waste processing power for nothing.
A structured e-invoice (UBL, Peppol or each country's tax formats) already comes with organized data and, often, a digital signature. The right workflow reads it directly, validates the schema and the signature, and reserves OCR for PDFs, images and paper.
That's why a good system has two entry points. Structured documents come in through one, and the ones that must be read with AI come in through the other, and both paths end in the same data model.
Recommended architecture: decouple so you don't get locked in
The healthiest architecture separates four stages that many products mix into a single black box.
Receipt: email, API, SFTP, supplier portal or e-invoicing network.
Interpretation: direct XML reading or AI-based IDP for images and PDFs.
Financial validation: supplier, arithmetic, taxes, duplicates and matching against purchase orders.
ERP integration: through an API, middleware, a file or, as a last resort, RPA.
The canonical invoice model
The glue between those stages is a canonical invoice model, a data structure owned by the company that doesn't depend on whichever OCR engine is in use. It includes supplier, number, date, currency, subtotal, taxes, total, line items, purchase order and a confidence score per field.
The practical advantage is huge. You can switch reading engines without touching a single line of the ERP integration.
It's the same principle we apply when integrating AI agents into manufacturing or automotive companies. There, plant and finance systems coexist across different technology generations.
Security, compliance and document retention
An invoice isn't just an accounting document: it contains personal data, tax identifiers, addresses and bank accounts.
Before signing with a SaaS platform, check these points in the contract:
Where the data is processed and backed up, and with which subcontractors.
Encryption in transit and at rest, multi-factor authentication and role-based access.
Audit logs that show who changed which field and when.
What happens to the documents when the contract ends.
It's worth asking explicitly whether your users' corrections are used to train other customers' models. The answer you want is a contractual commitment to no cross-training without authorization.
We explain how we handle this on our platform security and data transparency pages. It's part of the commercial conversation, not the fine print.
The original is never destroyed
Another non-negotiable principle: the AI layer creates a derived representation of the document, but never replaces the original. The repository must keep the received file, its hash (a kind of digital fingerprint), the receipt metadata and the digital signature if there is one.
If an e-invoice arrives signed, the system must validate and store the original XML. Converting it to PDF and keeping only that can erase exactly the elements that give it legal validity.
High confidence doesn't mean the value is correct
A model can be very sure and still be wrong. That's why high-impact fields (supplier, tax ID, number, currency, total, taxes and bank account) are also validated against master data, arithmetic rules and the purchase order.
Bank account changes deserve a separate process, with human verification through another channel. No OCR should be the only control against that kind of fraud.
How to set up a pilot that tells the truth
The pilot shouldn't answer whether the OCR works, but whether the platform can process your real mix of invoices and deliver correct, traceable and cost-effective data to the ERP without increasing accounting risk.
For that you need a representative corpus of 500 to 2,000 historical invoices, depending on volume and supplier diversity. It must include digital and scanned PDFs, photos, multi-page documents, credit notes, different currencies and, where applicable, structured e-invoices.
Keep a hidden part of the corpus for the final evaluation. If you train and evaluate with the same documents, the result will look too good to be true.
The metrics that really matter
Accuracy per field, separating the critical fields (supplier, number, date, currency, total and taxes) from the secondary ones.
Line accuracy: quantity, unit price and tax per line, which is usually much harder than the header.
Perfect document rate: percentage of invoices that needed no correction at all.
Straight-through processing: invoices posted with no human intervention, separating those with a purchase order (PO) from those without one.
False acceptance rate: invoices accepted automatically with an incorrect critical field, the most dangerous metric and the one that is measured least.
Human time per invoice, from the moment the exception is opened until it is approved, compared with the manual process.
Effective cost per invoice, adding license, usage, infrastructure, operations and human labor.
That last metric lets you make a real comparison between a SaaS and an open source solution. The OCR price per page tells only a small part of the story.
To track these figures without spreadsheets, a conversational BI agent like Metrix lets you ask in natural language how the perfect document rate or the cost per invoice has changed.
How much effort to expect
The timeline depends on the architecture you choose. A SaaS with an existing connector can have a pilot running in a few weeks, while a custom integration against the ERP's API takes on the order of two or three months.
A production-ready open source stack, with human review and security included, usually takes half a year or more. These are orders of magnitude for planning, not a universal standard.
What to ask a vendor before signing
A short list for any meeting with a vendor:
How it identifies the legal entity and the supplier on each document.
Whether it provides a confidence score per field and not just per document.
How human corrections feed back into the model and whether that learning stays private to the customer.
Which combination of keys it uses to avoid paying twice.
What happens if the same invoice is resent to the ERP (idempotency).
How to export documents, labels and metadata if you ever leave.
The answers say more than any published percentage. And if you would rather see the full flow working with your own invoices, you can schedule a demo and bring a real sample.
Frequently asked questions
What is the difference between OCR and intelligent document processing?
OCR converts images into text, but it does not understand what that text means. Intelligent document processing identifies the document type and extracts each piece of data with its meaning, using AI models that learn from corrections.
Is OCR needed to process e-invoices?
No, because an e-invoice structured in XML already comes with the data organized and can be read directly. OCR is only needed for unstructured PDFs, images and paper.
What is the most important metric in an invoice automation pilot?
The perfect document rate and the false acceptance rate are usually the most revealing. The first shows how many invoices go through with no correction at all, and the second how many were accepted automatically with a wrong critical field.
Is an open source solution a good fit for automating accounts payable?
It depends on the team's technical capacity and on volume. Free tools handle OCR very well, but the financial logic, the human review and the ERP integration have to be built and maintained.
How does invoice automation integrate with a custom ERP or one built natively on Salesforce?
Through a decoupled IDP layer that delivers a clean data model through an API, with webhooks and idempotency. The ERP remains the system of record, and the AI layer only hands it validated information, ready to post.
