Invoice processing automation: capture, check and approve

First determine whether structured invoice data is available. An appropriate electronic invoice can be parsed directly. A digital PDF with accessible text differs from a photograph or image scan. Germany's Finance Ministry explains the distinction between simple PDFs and structured electronic invoices. BMF electronic invoice guidance, checked on 26 September 2026.

Preserve the unchanged original and a stable case identifier. If one file contains several invoices, verify the split. If an invoice spans several pages, keep its lines and totals together. This relationship is a prerequisite for evaluating extracted fields.

File extension alone is not an adequate intake check. Damaged PDFs, protected files, blank pages and incomplete photographs need visible failure states. Lost inputs must not disappear from the later success calculation.

Extract the information required by the agreed process. A model may return many fields without every field needing to be copied elsewhere. Microsoft documents structured header and line-item output for its Invoice model. Microsoft invoice extraction.

The following example schema groups invoice fields into six field groups, each with a response to uncertainty:

For every field, define its format, required status and business owner. A missing purchase-order number may be normal for one supplier and a blocking issue for another. Put those distinctions into rules accounting can understand and maintain.

Supplier. A recognised supplier name is initially a text value. Selecting an accounting supplier is another decision. Use verified references and expose ambiguity. Similar wording must not silently select the wrong company.

Accounts, cost centres and projects. The same applies to accounts, cost centres and projects. AI can suggest a match, but valid values come from the destination or an approved mapping. New bank details should not update master data solely because extraction looks convincing. Such changes require a separate business control.

Raw, normalised and approved values. Retain raw, normalised and approved destination values where the distinction matters. This makes it possible to identify whether a mistake arose during recognition, transformation or business assignment.

Reuse of corrections. Define how corrections are reused. A reviewer fixing one invoice does not necessarily authorise a permanent rule for every future document from that supplier. Separate a case-level correction from an approved change to the mapping.

Check required fields, permitted formats and arithmetic relationships. Detect duplicates within the correct company and supplier context. Where relevant, compare purchase orders and confirmed receipts. A correctly read total does not prove delivery was justified.

How should confidence scores affect review?

Confidence scores can help route difficult fields to review, but they do not replace deterministic controls. A model can be confident about a value that belongs to the wrong business case. Choose thresholds using your test documents and the consequences of errors.

Which exceptions need a business decision?

Distinguish business exceptions from technical failures. An unknown supplier needs a matching decision; an unavailable destination requires an operational response. These should not enter the same endless retry loop.

The invoice. An invented invoice contains several lines, two tax rates and a separate discount. The model returns the total correctly but assigns one line to the wrong tax group. Checking only the gross amount would miss the error.

Proposed workflow. The proposed workflow extracts lines with source evidence and evaluates totals under accounting-approved rules. The discrepancy opens a review task. Accounting sees the original, extracted value and affected group. After correction, the checks run again and the approved version is recorded.

Handoff. The handoff uses exactly that version. If a corrected supplier invoice arrives later, it is connected to the existing case and reassessed. Approval for the earlier content does not silently apply to a changed document. This is a designed test scenario rather than proof of an executed integration.

Second test. Add a second test in which the model omits a line while maintaining a plausible header total. It should fail the completeness check when line-level data is required. This distinguishes a visually convincing result from an output fit for the intended workflow.

Export is complete only when the intended destination processing is acknowledged. Record the target identifier, time and state. If a response is lost, first determine whether the record already exists. Blind resubmission can turn a connection problem into a duplicate invoice.

Check source linkage as well as values in the destination. Future reviewers must be able to open the original from the record. A complete import without accessible evidence creates more searching and makes corrections harder.

Assign an owner to unresolved handoffs and record their age. A successfully extracted document waiting indefinitely for import is still unfinished work. Operational reporting should make that distinction visible.

Take a synthetic invoice with supplier reference EXAMPLE-SUPPLIER-7, invoice number INV-104, currency EUR and a gross total of €240. These are invented test values, not accounting or tax advice. The original file and each extracted value remain linked to case TEST-104.

Each stage of the synthetic handover produces a record and has a condition that stops automatic progress:

A repeated email should point to the existing case. If a reviewer changes the supplier, invalidate the earlier approval instead of silently reusing it. If the accounting system may already have accepted the write, investigate the existing record before attempting another creation. The expected result is one correctly assigned record, not simply a green workflow execution.

Documented connector operations. n8n documents invoice and contact operations for Xero, and separate Bill, Vendor and Invoice resources for QuickBooks Online. These sources were checked on 27 September 2026. They establish available connector operations, not a completed modernagents integration.

Payable object and mapping. For incoming supplier invoices, confirm the intended payable object rather than accidentally creating a customer sales invoice. Record the company or organisation, supplier identifier, currency, tax mapping and required state. Keep proposed values in a review queue until the accounting owner authorises the write. Do not assume that a state called “draft” exists or behaves identically in both products and every edition.

First test. The first test should include a wrong-company selection, an unknown supplier, a duplicate and a lost acknowledgement. Creating a record does not authorise payment or customer email. The integration directory sets out the documented routes and prerequisites; live account testing is required before presenting either route as a working implementation.

Include ordinary and difficult invoices: changing layouts, poor photographs, multipage documents, credit notes, foreign currencies, missing references and repeated submissions. Have expected values defined independently. Evaluate fields and complete transactions separately.

Measure incorrect, missing and invented information alongside remaining correction time. Include inputs the model could not process at all. A score calculated only from successful responses overstates operational performance.

Begin with one document category and one proven handoff. Expand once staff understand evidence, exceptions and ownership. Invoice extraction then becomes a manageable process evaluated against your documents rather than a general product promise.

These guides and service pages cover the decisions next to invoice processing automation:

• AI document processing: capture, review and transfer
• OCR, IDP or an LLM for document processing?
• Design an invoice approval workflow with clear ownership
• Detect duplicate invoices with business keys and review

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.