Invoices
Invoice processing software with OCR extraction
Invoice processing software removes the retyping between an invoice arriving and it being approved. DocumentMS imports invoices from a watched mailbox, reads them with OCR, extracts supplier, number, date and amount into metadata, then routes each one through the approval threshold its value triggers.
What goes wrong without invoice automation
Invoice processing is the clearest case for document automation because the work is entirely mechanical and entirely repetitive: an invoice arrives, someone reads it, someone retypes what it says into a finance system, someone else approves it, and someone files the original. Every step is necessary and none of it requires judgement until the approval.
The costs show up in three places. Late payment charges and lost early-settlement discounts, both caused by invoices sitting in an inbox. Duplicate payments, caused by the same invoice arriving twice by different routes with nothing comparing them. And audit friction, because reconstructing who approved a payment eighteen months ago means searching mailboxes.
The failure that costs most, though, is the invoice nobody can find. A supplier queries a payment, the invoice was emailed to an individual who has since left, and the organisation ends up paying again or arguing without evidence. That is a filing problem masquerading as a finance problem.
The symptoms you will recognise
- Invoices arriving in individual mailboxes rather than a monitored address
- Supplier, invoice number and amount retyped from a PDF into a finance system
- Duplicate payments discovered during reconciliation rather than prevented at receipt
- Approval evidenced by a forwarded email chain
- Early-settlement discounts lost because approval took longer than the discount window
- No single answer to "which invoices are awaiting approval, and with whom"
Configuration
Folder structure
Accounts payable
- Supplier / financial period
- Invoices awaiting approval
- Approved and posted
- Disputed and on hold
- Credit notes
Purchase documentation
- Purchase orders
- Goods received notes
- Contracts and rate cards
Supplier records
- Supplier onboarding and bank details verification
- Tax and compliance documentation with expiry
- Correspondence
Period close
- Accruals support
- Audit samples and evidence packs
Configuration
Metadata extracted from the invoice itself
| Field | Type | Mandatory | Why it exists |
|---|---|---|---|
| Supplier | Text | Mandatory | The primary retrieval key for a supplier query, and the basis of spend reporting. |
| Invoice number | Text | Mandatory | Combined with supplier, this is what makes duplicate detection possible at receipt. |
| Invoice date | Date | Mandatory | Determines the accounting period and, with terms, the payment due date. |
| Net amount / tax / gross | Currency | Mandatory | Drives the approval threshold and supports three-way matching. |
| Currency | Single-select | Mandatory | Prevents the threshold being applied to the wrong number in a multi-currency operation. |
| Purchase order reference | Text | Optional | Enables the match against order and receipt. Not all spend is on a PO, so it cannot be mandatory. |
| Payment terms | Number (days) | Optional | Makes the discount or due-date window reportable before it closes. |
| Cost centre | Single-select | Mandatory | Routes the approval to the right budget holder without anyone deciding who that is. |
Configuration
Approval chain
Step 1: Receive and extract
The invoice arrives at a monitored address and is filed automatically. OCR reads it, AI proposes supplier, number, date and amounts, and the content hash is checked against existing invoices.
Step 2: Match and validate
Where a purchase order reference exists, the invoice is matched against the order and the goods received note. Duplicate supplier-and-number combinations are flagged before approval, not after payment.
Step 3: Route by value
The cost centre determines the budget holder and the gross amount determines how many approvals are needed. Above a configured limit a second approver is added automatically.
Step 4: Approve, post and retain
Approval is recorded against the named approver and the specific invoice version. The invoice is posted to the finance system through the API, and retains under the tax record rule for its jurisdiction.
Configuration
Retention rule
What starts the clock
The trigger is the end of the accounting period or tax year in which the invoice falls, not the invoice date. Using the invoice date disposes of records from the start of a period before those from the end, which makes a period-based audit sample incomplete.
Outcomes
What changes
- Invoices arrive in one monitored place instead of individual mailboxes, so an absence is visible
- Duplicate supplier-and-number combinations are flagged at receipt rather than found during reconciliation
- Approval routing follows the cost centre and the amount, so nothing depends on someone knowing the threshold
- A supplier query is answered from a search rather than a mailbox, including after the original recipient has left
- Audit evidence for a payment is the approval record, not a reconstructed email chain
FAQ
Invoice processing: common questions
Does this replace our accounts payable or ERP system?
No. The finance system remains the ledger. DocumentMS handles the document side — receipt, extraction, duplicate detection, approval evidence and retention — and posts to the finance system through the API. The division is deliberate: document control and double-entry accounting are different problems.
How accurate is invoice extraction?
Structured fields on printed invoices read well; handwritten annotations and unusual layouts do not. On our own evaluation set, field-level accuracy is 97% on structured invoices and 89% on scanned or annotated ones, with supplier name, invoice number and total reading more reliably than line-item detail. That gap is exactly why extracted values are proposed with their source passage and confirmed rather than posted silently — a finance team needs to know which fields to check, not a single headline number.
Can it do three-way matching?
It can match an invoice to a purchase order and a goods received note where both are in the repository, and flag the discrepancy where they do not agree. Whether that constitutes three-way matching in your control framework depends on where the authoritative quantities live — often the ERP, in which case matching belongs there and the documents belong here.
What stops a duplicate payment?
Two mechanisms. Content hashing catches the identical file arriving twice by different routes. Supplier-plus-invoice-number matching catches the same invoice arriving as a scan and as a PDF, which hashing cannot. Both flag rather than block, because there are legitimate reasons for a resend.
When should the retention clock start?
At the end of the accounting period or tax year the invoice falls in, not at the invoice date. Otherwise records from January are disposed of months before those from December in the same audited period, and a period-based sample cannot be completed.
Última revisão: 2026-09-01. See all seven use cases.