Use an invoice harness for intake, with payment kept separate
Extract documents into a review queue, check the numbers and surface exceptions before accounting decisions.
A PDF invoice is a good example of where AI and ordinary rules have different jobs. The model can help read an inconsistent document. Arithmetic, duplicate checks and approval rules should not depend on a fluent explanation.
An invoice-intake harness separates those steps. The first version should prepare records for review, with no authority to pay suppliers or change bank details.
Define the record you need
Start with supplier name, invoice number, invoice date, currency, net amount, tax amount, total and source file. Ask for missing or unreadable fields to be marked explicitly. Preserve the original document for the reviewer.
Use a small set of synthetic invoices for the first test. There is no need to expose real account details while deciding whether the workflow understands your required fields.
Build the checks outside the model
A visual workflow might be: dedicated upload folder → document extraction → fixed output fields → arithmetic and duplicate checks → exception queue or review-ready record.
Check net plus tax against total using ordinary decimal arithmetic with an explicit rounding tolerance. Check likely duplicates using supplier identifier, invoice number and other relevant fields; do not rely on the filename alone. A renamed attachment can still be the same invoice.
A structured parser can help enforce the expected field layout. It cannot establish that the document is authentic or that the extracted values match the original. Read n8n’s structured-parser documentation.
Give exceptions a useful destination
If the currency is missing, the sums do not reconcile or two documents appear to represent the same invoice, route the record to a named reviewer. Include the failed check and the relevant source, rather than a generic error message.
Treat bank-detail changes and payment approval as separate processes owned by the finance team. A model-generated match or a well-formed record is not approval to move money.
Test behaviour at the boundary
Try a clean invoice, a duplicate with a new filename, a blurred total and a credit note. Decide how each should be handled before evaluating the workflow. A credit note must not silently become a positive invoice because the template expects a total.
Measure extraction corrections, duplicates missed and reviewer time. Include model usage, retries and exception handling when calculating cost per accepted record. A low-cost model may be enough for some documents; that is a result to measure, not a promise.
This harness can often be assembled from visual workflow components and existing document services. Connector availability and document quality determine how much configuration is needed. The practical benefit is a consistent intake process whose uncertain cases remain visible to the people responsible for the accounts.
