How to validate conflicting invoice amounts before ERP posting
When invoice amounts disagree, pause the affected ERP handoff. Keep the extracted amount, its location on the source and the calculated check value separate. Determine whether the system mapped the wrong figure, a documented rounding rule explains the difference, or the invoice itself is inconsistent. Resolve the discrepancy and rerun the checks before releasing the record.
Decide what each amount means and where it comes from
An invoice can show a gross total of €233.76 and an amount due of €183.76 after a prepayment. Both figures are correct. If the pipeline maps them to the same field, better character recognition alone will not help.
- Structured e-invoices: Read the XML directly. Validate it against the relevant syntax schema and profile rules. The European Commission recommends using the supplied validation artefacts alongside the applicable schema.
- PDFs and scans: Keep the extracted text, normalised decimal value, currency and location. This distinguishes a misread digit from a correctly read amount mapped to the wrong field. For the choice of extraction method, see OCR vs VLM vs parser.
- XML and PDF with conflicting values: Define which representation governs each intake workflow. Route unexpected conflicts for review. A high confidence score should not release a disputed amount.
Keep missing, unreadable and zero distinct. An optional prepayment that is absent under the applicable profile can be omitted from the calculation. A prepayment shown on a scan but too blurred to read is unresolved.
Run explicit checks on the extracted amounts
Use this matrix as an implementation starting point. The total and VAT relationships draw on Peppol BIS Billing rules BR-CO-10 through BR-CO-17. For structured invoices, validate against the actual profile. For PDFs, use the relationships as business checks. Passing the arithmetic does not establish format conformance.
| Check | What to compare | Failure it can expose |
|---|---|---|
| Line net amount | Invoiced quantity ÷ price base quantity × net price, less line allowances plus line charges; account for units | A price per 100 units is treated as a price per item. |
| Invoice net total | Sum of line net amounts minus document allowances plus document charges | A discount is deducted twice. |
| VAT | Compare taxable and tax amounts by VAT category and rate where applicable; add the tax amounts | An amount is assigned to the wrong VAT category. |
| Gross total | Invoice net total plus total VAT | A subtotal is read as the gross total. |
| Amount due | Gross total less amounts already paid, plus any stated rounding adjustment | A prepayment is missed or gross is mapped to amount due. |
| Currency and sign | Check invoice currency and document type; keep separate tax-currency amounts distinct | A converted amount is used for posting or a credit note is treated as an invoice. |
Use decimal arithmetic and specify where rounding occurs for each rule. A blanket percentage tolerance can allow a substantial discrepancy on a large invoice. If a PDF workflow accepts a narrowly defined rounding difference, record the rule and retain the stated amount.
Worked example: the ERP record is €50 too high
This example is fictional. Two lines total €125.00 and €79.80. After a €10.00 discount, the net total is €194.80. With €38.96 in VAT, the invoice shows €233.76 gross. After a €50.00 prepayment, €183.76 is due.
The extractor assigns €233.76 to the amount due. The line, net, VAT and gross checks all pass. The amount-due check catches the problem:
| Evidence | Value |
|---|---|
| Extracted amount due; source location is labelled “Gross” | €233.76 |
| Calculated amount due: €233.76 − €50.00 | €183.76 |
| Amount due stated on the invoice | €183.76 |
| Difference in the proposed ERP record | €50.00 |
Pause the handoff and show the reviewer the three relevant fields on the invoice. Here the reviewer can correct the field mapping and rerun the checks. If the source itself stated an inconsistent amount due, the responsible finance team would need to resolve the exception. The calculated amount would remain a check value.
Decide what can proceed, what needs review and what must stop
| Finding | Workflow decision |
|---|---|
| Required fields are unambiguous, traceable and pass the rules | Release for the intended ERP step once business checks also pass. |
| A documented rounding rule explains the difference | Follow that rule and retain the original value and validation result. |
| Two candidates could fill the same field, or a required value is unreadable | Hold the handoff and show the relevant source locations to a reviewer. |
| The source is inconsistent, currency is unclear or a business reference fails | Block the handoff until the responsible team resolves the exception. |
An invoice can balance and still be a duplicate or refer to the wrong purchase order. Keep amount validation, reference checks and posting approval separate. Creating a controlled ERP draft and posting an invoice are also distinct actions. The email, PDF and ERP automation guide puts those controls in the context of the wider workflow.
Start with a small acceptance test
Choose one document type, one intake channel and one ERP destination. Start with a clean reference invoice, then add cases for a prepayment, a price per 100 units, multiple VAT categories, a missing amount, a rounding difference and an invoice that does not balance. For each case, define the expected rule result, what the reviewer should see and whether an ERP write is allowed. In the prepayment example, the test should prove that the incorrect amount never reaches the ERP.
If you are evaluating a specific invoice workflow, share the document type, intake channel and ERP destination through the AI document processing service. This helps define the fields and exceptions the pilot needs to cover.