Purchasing
Checks budget before a commitment is made, compares supplier quotes on true landed cost, and makes the purchase order the instrument that authorises an order, not paperwork that follows one.
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
In most growing companies the order is placed first and the paperwork follows, so budget is discovered to be exhausted after the money is already committed.
Who feels it
Purchasing starts as a WhatsApp message to a supplier and a verbal approval. It works at small scale. Then the company has forty people ordering things, and finance is reconstructing what was committed from invoices arriving weeks later. The purchase order, if it exists at all, gets created to match an invoice — the exact opposite of authorising one.
The consequence is that budget is always historical. A department head sees what has been invoiced, not what has been ordered, so the remaining budget number is wrong in the one direction that matters. Two people can each commit the last of a budget in the same week and both believe they were within it.
Supplier selection has a parallel problem. Quotes arrive in different shapes — one includes freight, another quotes ex-works, a third offers a discount for payment in fifteen days, a fourth prices in a different unit. Compared on headline price, the cheapest quote is frequently not the cheapest purchase, and nobody has the time to normalise them by hand.
02Product overview
A requisition-to-receipt system where budget availability is calculated from commitments rather than invoices, approval is required before a purchase order is issued, and supplier quotes are normalized to a comparable landed cost before selection.
Engineering notes
The centre of the design is commitment accounting. A budget line has an allocation, and against it sit committed amounts from approved purchase orders, invoiced amounts, and paid amounts. Available budget is the allocation minus commitments, not minus invoices. Because commitment happens at approval, the number a department head sees is the number that is actually true, and two people cannot both spend the same remaining balance.
Requisitions carry what is needed and why, and route for approval by amount band, category and cost centre. Approval creates the commitment and authorises the purchase order, so the order document permits the spend instead of recording it afterwards.
Quote comparison normalizes to landed cost. Unit conversion, tax treatment, freight and delivery terms, and the financial value of payment terms are all applied before comparison, and the comparison shows the adjustments so a buyer can see why the apparently cheaper quote was not. Selection is recorded with a reason, which matters when the lowest quote is not chosen.
Receipt closes the loop. Goods received notes record what actually arrived, partial deliveries track a remaining balance per line, and receipt is what allows an invoice to be matched and paid. A purchase order not fully received stays visibly open rather than being assumed complete.
03Key features
10 capabilities. Every one of them is deterministic software — there is no model in this build, and nothing here is described as AI.
Purchase requests capture what, why, when needed and the cost centre, so approving one is a decision and not a guess.
Available budget is allocation minus approved commitments, so the figure reflects what is owed, not only what is invoiced.
Amount bands, category rules and cost centre ownership determine the required approvals, with delegation and escalation.
Requirements are sent to shortlisted suppliers with a response deadline and a structured response format.
Quotes are normalized for units, tax, freight, delivery terms and payment terms before they are compared.
Choosing a supplier requires a reason. That record is the one anybody reviewing the decision asks for when the lowest quote was not the one selected.
Issued only after approval, with sequential numbering, terms, delivery schedule and a generated document for the supplier.
Receipts record actual quantities with partial delivery tracking and a remaining balance per line.
Suppliers with tax details, bank details under change control, categories and a delivery performance history.
Committed against invoiced against paid by category, cost centre and supplier, sourced from the same ledger the checks use.
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
Requisition raised with cost centre and justification.
Budget availability computed from allocation less commitments.
Policy routing; approval creates the commitment.
RFQ issued; responses normalized to landed cost.
Purchase order issued with sequential number and terms.
Goods receipt with partial delivery balances; invoice match enabled.
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
A running balance is a cache of a calculation, and caches of financial calculations drift. Deriving availability from immutable entries means the figure is always consistent with the events that produced it.
Trade-off
Reads cost an aggregation, so hot budget lines use a maintained rollup that is verified against the ledger and never trusted as the source of truth.
Why
Approval is the moment the company decides to spend. Committing later leaves a window in which the same budget can be approved twice. Closing that window is the reason this system exists.
Trade-off
Cancelled orders need an explicit commitment reversal — an entry, never a deletion — so the history shows both the commitment and its release.
Why
Headline price comparison is wrong often enough to matter. Itemising the adjustments — unit conversion, tax, freight, payment-term value — makes the normalized number defensible instead of magic.
Trade-off
Requires structured quote capture, so quotes arriving as free-form documents need a data-entry step. The comparison is worth the typing.
Why
Order numbers are referenced by suppliers and auditors, so gaps and duplicates are both problems. A sequence claimed in the same transaction as the order row is the only approach that holds under concurrent issuance.
Trade-off
A rolled-back transaction can consume a number, leaving a gap. A gap with an explanation is far better than two orders sharing a number.
Why
Supplier bank account substitution is one of the most common payment frauds. Requiring a second approver and recording the previous details makes the change visible; without that, it looks like any other edit.
Trade-off
Adds friction to a legitimate update. That is the correct trade for the risk involved.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Commitment entries are inserted inside a transaction that takes a lock on the budget line and recomputes availability from the ledger before writing. The second approval sees the first commitment and fails the check with a specific message naming the remaining amount.
Outcome
Over-commitment became impossible, not merely unlikely. A budget check that can be raced is only a budget suggestion.
Approach
Every quote line is converted to a base unit, tax is applied according to the supplier’s registered treatment, freight is allocated across lines by value or weight depending on the incoterm, and payment terms are valued against a configured cost of capital. Each adjustment is retained and displayed next to the normalized figure.
Outcome
The comparison surfaced cases where a higher headline quote was the cheaper purchase, with the reason visible instead of asserted.
Approach
Receipt quantities are recorded per line per receipt, and the outstanding balance is derived from the order line less cumulative receipts. An order is only closed when every line is satisfied within tolerance or explicitly short-closed with a reason.
Outcome
Open orders are genuinely open. Finance stopped chasing deliveries that had arrived and stopped assuming ones that had not.
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.
Requisition form
Line items with the live budget position for the selected cost centre — allocation, committed, available.
Quote comparison
Suppliers side by side with headline price, each adjustment, and the resulting landed cost.
Purchase order
Approved order with terms, delivery schedule, receipt progress per line and the approval trail.
Spend by cost centre
Committed, invoiced and paid against allocation, from the same ledger the approval check reads.
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.