Technical detail
Safeguards
- Idempotent ingestion: the same invoice twice means one posting
- Poison queue and retry policy, with alerts on repeated SFTP failures
- Audit trail from email receipt to AP delivery
- No invoice content sent to public LLM APIs
Work / System · Integration
Purchase Invoice OCR
Purchase invoices from inbox to AP system, without manual keying.
A private accounts payable automation for a company. Vendor invoices arrive in Outlook, and a .NET pipeline extracts, validates, enriches and delivers them to the AP system.
- Status
- Live · private, in customer use
- What it is
- An internal pipeline that turns emailed PDF invoices into validated XML + PDF packages for the AP system.
- Who it's for
- One company's accounts payable team. A private, internal system.
- My role
- Pipeline design and implementation.
The problem
Vendor invoices arrive as PDFs in many layouts. Keying them by hand is slow and invites typing errors and duplicate payments.
Constraints
- The same invoice must never be posted twice
- Totals must be exact, so extraction is always checked by rules
- Invoice data stays inside the organisation
- The AP system accepts XML + PDF packages over SFTP
What I did
I designed the stages and their failure handling, and built the pipeline on .NET with Microsoft Graph and Azure Document Intelligence.
Main journey
- Input
Invoice arrives
A vendor emails a PDF invoice to a shared Outlook mailbox.
- Code
Ingest
Microsoft Graph API collects the message and attachment, and an idempotency key is assigned.
- Code
Extract
Azure Document Intelligence reads the header and line fields.
- Code
Validate and enrich
Rules check totals and VAT; vendor details are enriched and matched against master data.
- Code
Deliver
An XML + PDF package goes to the AP system by SFTP, with retry and a dead-letter queue.
- Person
Handle exceptions
Anything that fails a check goes to a person instead of being forced through.
Decisions and tradeoffs
No LLM in the posting path
OCR reads the document; rules and master data decide what is accepted.
Tradeoff: Unusual layouts become exceptions rather than best guesses.
Idempotency end to end
Keys survive duplicate emails and SFTP retries, so one invoice means one posting.
Tradeoff: Every stage has to carry and check the key.
Separate, observable stages
Ingestion, extraction, enrichment, validation and delivery run separately, with poison queues and reconciliation.
Tradeoff: More components to monitor than a single script.
Diagram only
The system runs inside the organisation, so I show the architecture, not screens or data.
Tradeoff: Less to see here; I walk through it in conversation instead.
Evidence
- Architecture walkthrough on request: duplicate handling, vendor enrichment, SFTP failure modes and reconciliation
No screenshots, company names or invoice data are shared.
Status and limitations
- Live: In use by the customer's accounts payable team
- Private: Internal system for one organisation
- Evaluated: Exception-email classification to route failures faster. Not part of the posting path.
Stack
.NET, Outlook, Microsoft Graph API, Azure Document Intelligence, Vendor enrichment, SFTP, XML + PDF packages
Have a similar process?
Tell me what you'd like to change. I'm in Helsinki (UTC+2) and work with clients in Europe and North America.