The engineering bottleneck with assembled stacks
Accounts payable clerks key VAT invoices by hand because the PDF is legally the document and the ledger is where payment happens; between them sits a person copying numbers. Errors are asymmetric and expensive — a transposed digit underpays a supplier or overpays a stranger — and month-end turns the queue into overtime with a magnifying glass.
Architecture on the Software Lifecycle Cloud
Each invoice is a bucket object and a record keyed by invoice id. The worker extracts header fields and line items, validates arithmetic (lines sum to total, tax rate matches the supplier’s country pattern), and parks discrepancies as review steps with the page shown beside the values. Only a human-approved invoice changes state to payable; the paying system reads approved rows, nothing else.
Arithmetic is the first reviewer
Before any human looks, cheap deterministic checks catch the expensive mistakes: line items that do not sum, totals that differ from the header, duplicate invoice numbers from the same supplier. Those checks run in the worker as ordinary code, versioned with the rest of the project — when a check proves wrong for a supplier’s format, the fix is a reviewed code change, not a support ticket to an extraction vendor.
- Duplicate invoice numbers are a keyed lookup away — the second arrival flags itself
- The approval step records who approved, when, and what the page showed at the time
- Payment systems read only the approved state; nothing unapproved can leak into a payment run
Audit without a second system
When finance asks why an invoice was paid, the answer is one project query: the object in the bucket, the extracted rows, the validation results, the approver, the timestamp. Auditors get evidence instead of a trail across an extraction vendor’s portal, an email approval, and a ledger note that disagree in the details.
Frequently asked questions
Good layouts extract cleanly; the design assumes imperfection anyway. Arithmetic validation routes suspicious totals to humans, and per-field confidence routes low-certainty reads. Accuracy is measured per supplier from the correction record, so problem formats are visible by name.
No — deliberately. The workflow ends at approved-for-payment; your bank, accounting package, or payment provider executes. Keeping extraction and money movement in separate systems is a control, and the approved table is the clean interface between them.
It extracts what it can and flags the rest. Image-heavy invoices go through inference-assisted reading in the worker, and whatever stays uncertain arrives at the human step with the page rendered — the clerk confirms values instead of typing them.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.