Launching a B2B payment system with every payment in one place

The finance team raised and paid invoices every day on a legacy system that worked but was old, slow to use and not connected to the rest of their software. To be sure where a payment stood, invoiced, paid, settled or past its deadline, people checked it two or three times across systems that did not talk to each other. 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.

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 worked. I built it in high fidelity against real invoice data, because what mattered was how it read at full scale.

One thing had to stay still: how the invoice looked. 90POE is a B2B SaaS product, and one of the world's largest ship managers, a fleet of around 200 vessels, 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 has to hunt for a familiar line pays late. At their scale a delay means millions. 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 we automated everything around it. Generated PDFs, checked fields, no retyping. Engineering's first answer was that the PDF generator could not be built in time. I asked what the constraint was. The team had not built one before, so the only risk was time. I brought the user testing to leadership, the sprint plan made room for it, and it shipped inside the MVP. Seeing the final document before sending was what made teams trust the automation.

Two teams used the module every day and needed different things from it. The wet team, tankers and disbursements, and the dry cargo team each had their own columns and filters. Neither needed to see the other's. Two products would have doubled every change for ever, so I tested one combined view first. Once the flow settled, the module started recognising which department was looking and showing that team's part, with its own filter settings saved. One product, two views. After launch, the analytics showed no drop-off and no unusual editing in either team.

I designed the permission model: three tiers, from view-only to full sign-off, and a two-approver chain on every invoice and payment, with a separate flow for a director's signature. It went through the client's IT and security review. Both 90POE and the client signed it off. 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.

I mapped the lifecycle before drawing anything. The mapping showed the problem was in reading a payment, which was already scattered across five places. Another screen would have made it six. The design took things away. Leadership had proposed a share link in place of a status view, to save engineering time for the MVP. This is money moving between companies, and a link sits unopened in an inbox. The testing settled it. The share link went. The whole payment sat on one screen, easy to read and to change, and engineering built the PDF generator inside the MVP.

In the five months after the MVP launched, $500M moved through the system. Every invoice went out on time. The platform had no finance module before this. The people on it: the operators who raised and matched invoices every day, the reviewers and approvers above them, and the client's own customers, who received the generated invoices. 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. Exception detection meant a stalled payment surfaced on its own. The pattern went into the design system and across the whole product. Three other teams picked it up immediately.

This was a 0 to 1 build. I owned it end to end. Payments sat at the centre of an integration ecosystem, where every design decision rippled into other systems and external APIs. I led design through delivery with the product manager, a solutions architect and a 15-strong engineering team. I mapped the lifecycle, shaped the scope and priorities, set the design 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. The module went through five gates to go live, from the team's product review to the C-suite and the client's own leadership. The client's finance team signed off every flow. I stayed with engineering through QA, checking edge cases before each release.

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.