Billing banks straight from their contracts

Pomelo is fintech infrastructure for Latin America: banks and fintechs use it to issue cards and run account programs. I joined in 2021 as a senior designer on the partner dashboards and stayed almost four years, the last year and a half leading the UX team and still designing billing and automations myself.

This case is about billing. Pomelo charges every client for the cards it issues and the transactions it processes, each on its own contract, currency and tax rules. When I picked it up, all of that was done by hand. Someone in finance read each contract PDF and typed the numbers into a spreadsheet, for 77 clients in five countries, and only 22% of invoices went out on time.

Role

Senior product designer, then leading the UX team, five people and about seven at one point

When

2023 – 2024, within 2021 – 2025 at Pomelo

With

Product, engineering and finance

Scope

Billing for banks and fintechs across four tax regimes

The decision

Start with sending invoices from one place, and build toward entering each contract once and deriving everything from it

What changed

On-time invoices 22% → 95% · unpaid bills $6M → $3M · no external billing teams

Prices nobody could query, quantities nobody had yet

Prices lived in private contracts that no system could read. Quantities were supposed to come from a data lake that hadn’t been built yet. And invoices went out under four regimes: electronic invoicing in Argentina, NF-e in Brazil, CFDI in Mexico, and government pre-authorisation in Colombia. The tax side was for engineering and finance to build, and I wasn’t the one solving it.

Starting with the part we could build

The contracts were digital, but nothing stored what was in them in a form the data and engineering teams could use. No system had the price, so no system could multiply it by a quantity, and calculating invoices automatically was blocked until other teams digitised the contracts. Billing covered three products, Cards, Identity and digital accounts, and Cards was by far the most complex: eleven concepts, each of which could change by client, country, contract and card brand.

So we started with the one step every invoice has in common, which is sending it. At the time all of them went out by hand, one by one, four to seven for each client, each email carrying a detailed summary of that client’s operation. Nothing stopped an invoice for one client from going to another, and that had already happened once. Payments were followed by hand too, in one mega-file where the team marked who had paid what (its real name was Global Tracker). Nobody measured whether a client had received what we sent. Starting there also meant building the place where the contract details would live, such as which day to send and to which addresses, which the later calculation would need anyway. The first users were Pomelo’s own billing team, who were doing all of it by hand.

In the backoffice we drew one screen to upload an invoice and describe it, with its number, currency, period and the concepts it bills, and one to set, for each client, the day its invoices go out and the addresses they go to.

The contract as the source of truth

We decided to enter each contract once and derive everything else from it: invoices, reminders, balances. I split the work into two tracks that ran in parallel. A backoffice, where finance sets up a contract and the system generates the invoices, and a dashboard where partners see every invoice and pay it.

We drew the backoffice from the client down, since everything billed belongs to one: a client has its data, its contracts and the products it is billed for.

Under a client sit a price addendum and the contract itself. The addendum holds the prices and when each is billed, and the contract is one long form with a block for each price rule.

We wireframed together in Excalidraw with the whole team on a call. Before drawing any screens, I wrote down every state an invoice can be in: pending, reported, paid, overdue, partially paid, or reversed with a credit note. The partner dashboard is built around those states, so a partner can always tell where a bill stands without having to ask anyone.

The partner dashboard that came out of them lists every invoice, with a drawer that shows the PDF and a pay action, and lets a partner report a payment with the bank details and, for Brazil, a PIX code.

We also drew the invoices with a second tab for the ones not yet issued, with what has accrued toward each and the days left before it goes out. Paying is a short form, and so is reporting a problem with an invoice, which opens with the invoice’s own data already on it.

Behind the partner’s view is the backoffice, where finance works. When an invoice that has already gone out needs correcting, they raise a credit note against the original, line by line, and the invoice goes to the state the spec says it should.

Six small things from the dashboard and the backoffice, close up and set moving, with placeholder data: where an invoice stands, a row’s actions, sending an idea, copying a number, which concepts are billed and a tour of the page.

Three A/B tests, and what each moved

We ran three A/B tests along the way. A direct payment reminder got 20% more payments before the due date than one that explained the context. A PIX code on Brazilian invoices, which clients there had asked for so they could scan a QR and pay directly, made no difference in the test. We shipped it anyway, and as far as I know it stayed. PIX carries a lot of weight in Brazil today. And taking the amount out of the notification email raised platform DAU by 8%.

That last one won, and I argued against it. It meant hiding the amount to get people into the platform. We tried several variants of that email, and I don’t remember which one stayed.

Matching payments was the bigger problem

Billing turned out to be a small part of something larger. It grew into collections, finance, reconciliation and payments, all built from nothing, and reconciling payments was the hardest of them. Pomelo had a banking licence, so we considered giving each client its own CBU to pay into. The limits on transfers to a CBU did not allow the amounts clients had to pay, so it was not an option. We threw away a lot of ideas like that one.

Leading the team while designing billing

Through this project I was also leading the UX team, and I had more or less started before the title said so. It was five people, about seven at one point. Leading it meant hiring, planning, estimating the workload and working out how many people it needed, while I kept designing billing and automations myself as a senior. A lot of that was above my pay grade at the time.

What I learned there is that culture and a healthy place to work are almost everything, and so is trusting the people on your team (I know it sounds like feng shui). We had a good time working together, and I still keep in touch with every one of them. I also think a design lead has to stay hands-on: one who can’t keep up with the tools, the systems and the problems the team works on, or decides not to, can’t lead it well.

What changed

Looking back, the order is what I would keep: we started with the one step nobody else had to build first, sending the invoices, and the place we made for it, with each client’s send day and addresses, was built to hold what the calculation would need later. Collections, reconciliation and payments grew out of it, all from nothing.