AI invoice processing with Azure, .NET and Business Central
Architecture: keep document intake, extraction and approval separate
An invoice is not a simple chat prompt. It may contain multiple pages, line items, multiple tax rates and poor-quality scans. Build a traceable pipeline: intake → immutable original → file checks → text/OCR → structured extraction → deterministic validation → human approval → ERP handoff. Every stage should have a recorded status and an independent recovery path.
1. Intake and duplicate detection
Assign a document ID and preserve the original in a secured DMS or blob store. Check file type, size and malware risk where appropriate. A SHA-256 hash detects identical files; business duplicate detection also needs vendor, invoice number, date and company or tenant. Two differently encoded PDFs may represent the same invoice.
2. Extract text before choosing OCR
First inspect the embedded PDF text layer. Check that columns, ordering and characters remain meaningful. Run OCR for scanned or otherwise unreadable pages. OCR identifies text but does not independently establish the business meaning of an invoice number, line-item unit price or tax amount. Preserve page references or bounding locations so a reviewer can locate each value in the original.
3. Define a strict structured contract
Agree on the output schema before selecting a model. For example:
{
"supplierName": "Example Supplier Ltd",
"invoiceNumber": "INV-2026-1042",
"invoiceDate": "2026-10-01",
"currency": "EUR",
"netAmount": 100.00,
"taxAmount": 19.00,
"grossAmount": 119.00,
"lineItems": [
{ "description": "Service", "quantity": 1,
"unitPrice": 100.00, "netAmount": 100.00 }
]
}
This is a sample output, not an extraction from a real document. Validate the schema and data types in .NET. Syntactically valid JSON does not establish factual correctness. An absent or unreadable value should be marked unknown rather than invented. Prompt instructions are useful, but cannot replace independent validation.
4. Deterministic validation in C#
Business-critical checks should be implemented in code, not delegated entirely to the model. This simplified example checks a total within a tolerance; real tax handling needs jurisdiction-specific rounding and multiple tax groups.
public static bool TotalsMatch(
decimal net, decimal tax, decimal gross,
decimal tolerance = 0.02m)
{
return Math.Abs((net + tax) - gross) <= tolerance;
}
Use decimal for monetary values. Independently validate dates, currencies, tax amounts, duplicate invoice numbers, supplier records, bank-account changes and line-item subtotals. Foreign-currency invoices and credit notes require explicit handling.
5. Match the supplier in Business Central
AI may propose a vendor match, but similarity of names is not sufficient authorization. Combine tax registration numbers, known addresses and approved bank details. Uncertain records belong in a review queue. Changes to bank details require especially strong controls. Create draft data in Business Central only after the match is established; automatic posting should be limited to explicitly approved low-risk cases.
6. Design effective human review
A useful review interface displays the source document beside extracted fields, source locations and uncertainty indicators. Reviewers need to edit incorrect values and record who changed and approved them. Separate capture, approval and posting duties where required. An LLM's self-reported confidence is not a universal percentage of correctness: calibrate thresholds against representative evaluation documents.
7. Security, privacy and cost
Invoices may contain confidential information and personal data. Minimize information sent to external AI services, check processing terms and permitted data locations, and enforce access controls over stored documents. Record model, version, token consumption, cost, latency and review status without placing full invoice contents or credentials into logs. Include OCR, storage, search indexing and operational expenditure in the total cost estimate.
8. Reliability and recovery
Process jobs asynchronously with durable identifiers. A timeout must not cause multiple Business Central documents to be created for the same invoice. Persist an idempotency key built from the tenant, source and business invoice identity. Distinguish transient infrastructure failures from business validation failures. After changing the model or prompt, run regression tests against a controlled set of anonymized invoices.
9. Test scenarios
- Multi-page invoices with multiple tax rates and item totals.
- Low-resolution scans and rotated pages.
- Unknown suppliers and changed bank details.
- Duplicate invoices represented by different PDF files.
- Foreign currencies, credit notes and negative amounts.
- Failure after extraction but before ERP submission.
- Inconsistent totals, missing required fields and unreadable values.
Conclusion: Extraction alone is not an invoice-processing solution. Source traceability, deterministic validation, human approval and reliable ERP handoff are the essential supporting controls.
Discussion (0)
No comments yet. Be the first to contribute.