Accounts payable
Matches supplier invoices against purchase orders and receipts, routes only the exceptions, and moves approvals out of email into a policy-driven chain.
Build effort, not elapsed calendar time. Engagements ran alongside study and employment, so this figure is the work itself rather than the span it sat in.
Interface built in code for this case study — not a client screen capture.
01Business problem
Invoice approval lives in email threads, three-way matching is done by eye, and nobody can say what the company owes this month until someone rebuilds the number in a spreadsheet.
Who feels it
Accounts payable in a mid-sized business is a chain of forwards. An invoice arrives, someone forwards it to the person who ordered the goods, who confirms receipt in a reply, who forwards it to finance, who checks it against a purchase order in another system, who forwards it to a director for sign-off. Every step is a place where the thread stalls and nobody knows whose turn it is.
The specific, expensive failures are consistent across companies: duplicate payments when the same invoice arrives twice through two channels; quantity and price mismatches against the purchase order caught only after the money has left; approvals given by someone without the authority for that amount; and no reliable view of accrued liabilities, because unapproved invoices are sitting in inboxes and not in a system.
This is a workflow problem more than a reading problem. Extraction gets an invoice into structured form, but the value is in what happens next — matching, exception handling, authority, and a payment run someone can defend.
02Product overview
An accounts payable workflow that captures invoices, matches them against purchase orders and goods receipts within configurable tolerance, detects duplicates before they are paid, routes exceptions to the right owner, and enforces an approval chain derived from spend policy.
Engineering notes
Invoices are captured and extracted into a structured document, then immediately checked for duplication against existing records using supplier identity, amount, date proximity and invoice number similarity. A suspected duplicate is blocked and surfaced next to the record it resembles. It never enters the approval flow to be caught weeks later by a bank statement.
Matching compares invoice lines to purchase order lines and to goods received notes. Quantity and price tolerances are configurable per supplier category, and the result is not a pass or fail but a typed set of exceptions — over-billed quantity, price variance, no purchase order, partial receipt, unexpected charge line. Each exception type carries an owner role, so routing needs no human triage.
The approval chain is derived from policy; nobody picks it. Amount bands, cost centre, exception presence and segregation-of-duties constraints produce an ordered list of required approvals. A person who raised the purchase order cannot be the sole approver of the invoice against it, and an amount above a band requires the next level regardless of who is available. Cleared invoices collect into payment runs that export in the format the bank or ERP expects.
03Key features
10 capabilities, of which 3 are model-backed. The rest are ordinary deterministic software, and the distinction is marked so the AI claim stays honest.
Supplier email, upload and forwarded attachments enter one register with a processing state, so an invoice cannot sit unrecorded in an inbox.
Header fields and line items are extracted with confidence, and low-confidence values are held for review before matching runs.
Supplier, amount, date window and invoice-number similarity produce a duplicate risk score that blocks a payable before it enters approval.
Invoice lines are matched to purchase order lines and goods receipts with per-category quantity and price tolerance.
Mismatches become named exception types with an owning role — never a generic failure that lands back on finance.
Required approvals are derived from amount band, cost centre, exception presence and segregation-of-duties rules.
Out-of-office delegation is explicit and time-bounded, and an approval that ages past a threshold escalates; it does not wait silently.
Cost centre and expense account are suggested from supplier history and line description, with the suggestion always editable.
Approved invoices batch into a run with due-date grouping, early-payment discount flags and an export for the bank or ERP.
Approved, pending and disputed totals by supplier and due period, sourced from the register and never reconstructed in a spreadsheet.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Channel intake, register entry, processing state per invoice.
Header and line extraction with confidence and review hold.
Duplicate detection against supplier, amount, date and number similarity.
Three-way match with per-category tolerance producing typed exceptions.
Policy-derived chain with delegation, escalation and segregation of duties.
Payment run batching, export, and posting back to the register.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
If the chain were recomputed on every render, a policy edit mid-approval would change who was required after some approvals were already given. Freezing the resolved chain keeps an in-flight approval coherent.
Trade-off
A genuine policy correction needs an explicit re-resolve action with its own audit entry. That is the correct amount of friction for changing who must sign off.
Why
A price variance and a missing purchase order need different people and different resolutions. Typing the exception makes routing automatic; without the type, everything falls back to finance.
Trade-off
The exception taxonomy has to be maintained as new failure modes appear, and an unrecognized mismatch needs a catch-all type that still routes somewhere.
Why
A duplicate that enters the approval flow accumulates real approvals, and unwinding those is worse than a false block. Screening first makes the failure recoverable.
Trade-off
Legitimate similar invoices — recurring monthly charges of the same amount — get blocked and need a one-click override with a reason, which is recorded.
Why
A warning gets clicked through. Making "requester cannot be sole approver" a constraint that the resolver must satisfy means the invalid state cannot be reached at all.
Trade-off
In a small team the constraint can be unsatisfiable, so the resolver returns an explicit blocked result naming the constraint that failed. It never degrades quietly.
Why
Accounts payable is the part of a business most likely to be audited and disputed. Reconstructing state from events means the history is the source of truth, not a side effect of it.
Trade-off
Reads need a fold or a maintained projection. The fold is centralized so no component reimplements it.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Duplicate scoring combines supplier identity, amount equality, date proximity and normalized invoice-number similarity, and it treats a matching invoice number as decisive while treating amount-and-supplier alone as suspicious rather than conclusive. A known recurring-charge pattern per supplier further lowers the score.
Outcome
Genuine repeats pass through while true duplicates — the same invoice arriving by email and by upload — are caught before an approval is given.
Approach
Matching runs against cumulative received quantity across goods receipts rather than a single receipt, and tracks the remaining balance on each purchase order line. An invoice for a delivered part is a clean match; an invoice exceeding cumulative receipt is an over-billing exception.
Outcome
Staged deliveries stop generating exceptions that finance had to dismiss by hand. An exception queue is only worth reading while nobody has learned to ignore it.
Approach
The approval view shows the invoice, the matching result, the supplier’s recent invoice history, the purchase order it draws against with its remaining balance, and the position of this approval in the chain. Everything is server-rendered in one pass, so the screen arrives complete and does not fill in piece by piece.
Outcome
Approvers stopped replying to ask what they were approving, which was the real bottleneck in the email version of this process.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Invoice register
Every payable with supplier, amount, due date, match state and current approver — filterable by exception type.
Match inspector
Invoice lines beside purchase order lines and cumulative receipts, with variance and tolerance shown per line.
Approval chain
The resolved chain with the policy rule that required each step, completed approvals, and the current owner.
Payment run
Cleared invoices grouped by due date with discount flags and a total, ready to export.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
11Technical preview
There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.
Technical preview
Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.
A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.
Inside this section
For private client work, contact me for a walkthrough.
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.