The problem
Supply chain finance lets a supplier get paid early against invoices raised on a large buyer — the anchor — with the bank funding the gap. The commercial logic is simple. The operational process was not: it ran half on paper, across an anchor, its counterparties, a relationship manager, and a bank approval chain, with regulatory instruments that had to be signed before money moved.
A financing process split between a portal and paper, slow to move and hard to track.
A financing request is not one decision. It is a chain of them, made by different people with different authority, against validation that can fail at several points — and each failure needs somewhere to go that is not a dead end.
Give a multi-role financing request one state model that every participant reads the same way, including when it fails.
Constraints
- Multi-party, multi-role
- Maker, Checker, Authoriser and Sender, with multi-level authorisation above a threshold. Which of these roles exist, and who may act at each step, is configurable per service and per organisation — not every flow carries every role.
- Regulatory instruments
- Financing is executed through instruments that must be generated and signed. Nothing disburses on a screen action alone.
- External validation dependency
- Invoice data is checked against registry data the bank does not control. Those checks fail routinely, for ordinary reasons.
- Bulk with individual outcomes
- Suppliers submit invoices in files, but each invoice can pass, fail or be rejected on its own terms.
Key decisions
Make the file the unit of workflow and the invoice the unit of state
- Suppliers submit invoices in bulk, but validation, approval and rejection all resolve per invoice. Treating a submission as a single object would have forced an all-or-nothing outcome on a process that is routinely partial.
- Validation on a real file resolves three ways — full pass, partial pass, or fail — and a partial pass is the common case, not the edge case.
- Failing a whole file because some invoices did not validate pushes the correction work back onto the supplier and restarts the approval chain. Holding state per invoice inside a file that moves as one lets the valid portion keep moving while the rest is resolved.
- Every list, review and approval screen shows a file-level position and a per-invoice breakdown together. Partial processing became a first-class outcome with its own screens rather than an error condition.
Route validation failures to a person, never to a dead end
- Invoice data is validated against external registry data. Format errors, missing records and duplicate invoice numbers are ordinary events, and a document that cannot be read automatically cannot simply stop the request.
- The failure modes are well-defined and recurring: invalid GSTIN format, PAN not found, duplicate invoice number, failed field checks, and documents that defeat automatic extraction.
- Automation that fails silently converts into support load and abandoned requests. Each failure mode has a different owner — some belong back with the maker, some belong with operations — so the design routes by failure type rather than surfacing one generic error.
- Named resolution screens per failure type, and an explicit fallback path where automatic extraction fails to an operations queue, so the request stays alive and visibly assigned instead of stalling with the maker.
- Every failure state has an owner and a next action on screen.
Keep the two instrument paths mutually exclusive at submission
- Financing can be executed through different instruments with materially different downstream steps, signing requirements and tracking. Allowing that choice to stay open would have made every later screen conditional on it.
- The two paths diverge almost immediately after submission and never reconverge — different documents, different signing flows, different completion semantics.
- A branch taken late has to be carried through every screen after it. Forcing the choice at submission keeps each path linear and legible, and keeps the approval chain reading one document set rather than two possible ones.
- The instrument is chosen at submission and the request follows one path from there. Signature progress is tracked per instrument, so a request can sit legitimately in a partly-signed state without being either complete or failed.
Model authority as role plus level, not as a sequence of screens
- Approval is not one step, and it is not the same shape twice. Which roles exist, and who may act at which point, varies by service and by the organisation using it. Authority also varies by value, the counterparty runs its own chain in parallel, and exceptions need a legitimate lower-friction route without becoming a bypass.
- Above a threshold, authorisation runs through multiple levels; the counterparty side runs its own chain; an exception approval mode exists alongside the standard signed one; and role availability is configuration, not a constant.
- Building approval as a screen sequence means every new authority rule, and every organisation with a different structure, becomes a new screen. Modelling role and level as data lets one review surface serve a first-level authoriser and a final one — and lets a client whose structure omits a role use the same product.
- One review surface parameterised by role and level, showing where a request sits in its chain, who has acted, and who is next. The exception approval mode is visibly marked as an exception wherever it is used, so it stays auditable.
Where this stands
The workflow, state model and approval architecture were designed end to end. The artifacts on this page are reconstructed from my own working files, with client-identifying data removed.