90POE: a payment system that moved $500M

Follow the money first

Every morning the finance team opened several screens to follow one payment, some of it still in Excel. Nobody could say where a payment stood: invoiced, paid, settled or past its deadline. So I started by mapping the whole lifecycle with the product manager, finance, operations and engineering, from estimate to settlement. The finding reset the project.

See where the money is, at a glance.

Before · five places to look

Approvals screen
Payments screen
Excel tracker
Email, to chase status
Document folder

After · one place to read

Progress and Notes

The whole payment on one rail. Status, approvals and notes, in the order the team works, so you always know where a payment stands.

Five places became one.

One place to read a payment

I pulled a payment's whole history into one view, Progress and Notes, sitting right beside its invoice. Status, approvals, comments and whatever still needed attention, in the order the team actually worked. I built it in high fidelity against real invoice data, because what mattered was how it read at full scale.

View my comment

Leadership had asked for this feature, so my opinion alone wasn't going to settle it. I tested it with 32 users and brought the data instead. That made it an easy decision for everyone to stand behind.

The Voyage Manager invoice view, approval and payment history on one rail (draft created, submitted, approved, payment recorded) beside the generated invoice document. — One invoice's lifecycle on a single rail, draft created to payment recorded, with the generated document alongside.

Keep the invoice familiar

One thing had to stay still: how the invoice looked. 90POE is a B2B SaaS product, and one large client was moving its whole company onto it as part of a wider transformation programme. Their invoices go out to their own customers, and a customer who suddenly can't find what they used to is a payment that slips. At their scale a delay means millions. So they asked for a new invoice that stayed consistent with the one their customers already knew.

I held one rule with their transformation team: the invoice stays still, everything around it changes. The document kept its familiar design while everything around it was automated. Generated PDFs, checked fields, no retyping. Under a tight deadline I made the case to keep the PDF preview in scope. Seeing the final document before sending was what made teams trust the automation.

View my comment

A modern redesign would have demoed well. But these invoices go out to the client's own customers, and a document that suddenly looks different is one people hesitate to pay. Keeping the design consistent kept the money arriving on time.

The invoice stays still while the form does the work, generated live down to the stamp task it raises.

The bank-and-payment form, from bank details down to the stamp-requirement task — The invoice stays still while the form does the work, generated live down to the stamp task it raises.

Approve once, status everywhere

Approvals were routed by permission level. Once something was approved, the status updated on its own, with no more chasing by email. Testing made the screen simpler. A four-level action footer became one line of buttons.

The status view I rebuiltInteractive

$1.42Mcleared this week

7on track

Invoice	Counterparty	Amount	Status
INV-2051	Meridian Chartering	$486,200	Cleared
INV-2048	Port of Valencia	$512,800	Cleared
INV-2044	Aurora Shipping Ltd	$164,900	On track
INV-2039	Hanse Bunker GmbH	$421,000	9 days waiting

Why one screen won

I mapped the lifecycle before drawing anything, and the mapping showed the problem was reading, not recording. Another screen would only have added a sixth place to look for a payment already scattered across five. So the design took things away instead. I killed the share link and put the whole payment on one screen, easy to read and to change, and got leadership buy-in to build the PDF generator inside the MVP rather than after it.

What it changed

In the five months after the MVP launched, $500M moved through the system and every invoice went out on time. What shipped went well past the single view this page opens on: the full finance module, a programme of automation upgrades across invoicing, approvals and document workflows. Automated document generation ended the retyping that had caused the errors, and exception detection meant a stalled payment surfaced on its own. The pattern went into the design system and across the whole product, and three other teams picked it up immediately.

This was a 0 to 1 build and I owned it end to end. Payments sat at the centre of an integration ecosystem, every design decision rippled into other systems and external APIs, so I led design through delivery with the product manager and the solutions architects. I mapped the lifecycle, made the scope calls and set the direction, and led the invoice generator from design through build: a year of sprint-by-sprint delivery with user testing throughout, working with the client's transformation team to land the change across their company. I stayed with engineering through QA, checking edge cases before each release.

Reflection

What survived was one rail to read, and an invoice that kept the design customers already trusted. On a programme this size the judgement that matters is knowing what to push into the background, and you only earn it by learning the whole lifecycle first.