new businesses waiting to launch, because accounting setup could not keep up.
↳AMAZON · FINANCE · THE SHORT VERSION
Amazon was doing its books by hand.
The most digital company on earth moved billions between its own companies in a spreadsheet.
If none of this means anything to you yet: Amazon is not one company. It is hundreds of separate legal ones that constantly buy and sell from each other. Every internal payment has to be recorded and agreed by both sides. That job was being done by hand.
- Role
- UX lead · product strategy
- Team
- PM · Eng · Accounting · Tax
- Timeline
- Within Amazon · 2019–24
- Outcome
- 90% Q1 · $20M yearly
How much time do you have?
FIRST, THE STRANGE PART
Amazon isn’t one company. It’s hundreds.
Amazon US. Amazon Germany. AWS. Amazon Japan. Each its own legal business.
They trade constantly: server capacity, advertising, devices, shipping.
Every exchange is real money. Both sides have to record it, agree the amount, and pay it.
650+relationships between Amazon’s own companies
Roommates splitting bills. Now hundreds of roommates, and the bills are in the billions.
NOW THE PART THAT SURPRISES PEOPLE
There was no software for this. There was a spreadsheet.
Every month, someone checked hundreds of relationships by hand, one line at a time.
The approval that released a payment lived in an inbox. The rule for recording it lived in one person’s memory.
All of it had to balance to the penny, by a deadline nobody could move.
MONTH END00:00
Amounts redacted. Hundreds of lines, tied by hand, against a clock.
Two words worth knowing
When two Amazon companies trade, both sides record the amount separately. Matching is checking those two records agree. Settling is moving the money and closing the entry. Get either wrong and Amazon’s published numbers are wrong.
WHAT IT WAS COSTING
a year on outside software bought to paper over the gaps. It never closed them.
a fixed deadline to close the books, however long the manual checking took.
WHAT WE BUILT
Three things, made to talk to each other.
Describe the business. Get the bookkeeping.
You describe the business in ordinary language — what, where, how the money arrives. The system derives the accounting behind it.
Finally, you could see the money move.
Every transaction between two Amazon companies on one screen: matched, unmatched, overdue — and one place to settle it.
Write the rule once, properly.
Rules stopped living in documents and memory. Written once, checked as they are written, used everywhere.
THE HARDEST PART
At eleven at night, on deadline, is this still the easier choice?
We were never competing with another product. We were competing with a spreadsheet: free, familiar, already open. People fall back on what they know under pressure, and the last night of the month is nothing but pressure. That question settled almost every decision we made.
WHAT HAPPENED
It held.
saved year over year, once the manual work and the outside software went away.
of people moved onto the platform in its first three months.
relationships that used to be handled by hand, now handled by the system.
The middle number is the one that counts. The spreadsheet stayed available the whole time. Nobody was forced off it. People stopped reaching for it.
That’s the story. There’s more underneath it.
↳AMAZON · FINANCE TECHNOLOGY
The Ledger, Digitized
What I was hired to do, how I did it, and what changed as a result.
- Role
- UX lead · product strategy
- Team
- PM · Eng · Accounting · Tax
- Timeline
- Within Amazon · 2019–24
- Outcome
- 90% Q1 · $20M yearly
How much time do you have?
START HERE
Three things to know before any of this makes sense.
It is hundreds of separate legal ones — Amazon US, Amazon Germany, AWS, Prime Video — and they buy and sell from each other constantly: server capacity, advertising, shipping, devices. 650+ such relationships, every one of them real money.
Both companies record the same transaction separately, and the two records have to match exactly, then be paid, then be filed — against a monthly deadline that never moves. That work is called closing the books.
None of it had ever been software. No competitor to study, no prior art, no existing screen to improve. What I was replacing was a spreadsheet, an inbox, and a policy document on somebody’s desktop.
Describe the business in plain terms; it works out the accounting.
Every payment between two Amazon companies, on one screen.
The accounting rules, written once and checked as they are written.
01 · AT A GLANCE
None of this work had ever been software. There was no screen to improve, and no competitor to study.
02 · SCOPE OF THE ROLE
What I owned, what I shaped, and who with.
I OWNED05
I SHAPED05
I WORKED WITH05
03 · HOW I LED
Go where there is nothing to copy.
No competitor to benchmark, no prior art, no existing screen. So the research was pure observation: sitting beside accountants through real settlements and real month-end deadlines, mapping every manual step, every point where human judgement entered, and every point where information quietly got lost.
Turn observation into a shared model.
Nine documented user types, defined by what each person is responsible for, the words they use, what they are allowed to see, and what happens if they get it wrong. Not age and job title. Three product teams stopped arguing from anecdote and started arguing from the same map, and that model outlasted every individual design decision on the programme.
Make the architecture the design decision.
Three laws, set before a single screen was drawn: translate what the business says into what accounting needs, expose where a settlement actually stands so anyone can check it, prevent mistakes while a rule is being written rather than after it is live. Every screen downstream is a consequence of those three.
Define success as behaviour.
Not satisfaction scores. Whether people stayed in the product during month-end, when the free and familiar spreadsheet was one click away. Agreeing that measure up front is what made the result arguable afterwards.
04 · RANGE, IN ARTIFACTS
Research through production UI.
Eight real pieces of the work, labelled by the kind of thinking each one needed. Click any of them to view full size.
RESEARCH
PRODUCTION
05 · THE THREE PRODUCTS
Different people, different risk, one shared way of working.
Recordings come from the working prototypes, with sample data. Names and figures in them are fictional.
FULCRUM · STARTING A NEW BUSINESS
Business facts in, finished accounting out.
A step-by-step flow that lets the person launching a business (a Business TPM) describe it in their own language, while the platform works out the accounting entries Finance needs from it.
UNBLOCKED 100+ LAUNCHES
ICSE · SEEING THE MONEY MOVE
Every payment visible, where only Excel existed.
How long each amount has been outstanding, which records agree and which do not, the largest transfers first, and every way of paying — part of it, all of it, or more than the recorded amount — in one flow.
FOR ACCOUNTANTS · 650+ RELATIONSHIPS OFF SPREADSHEETS
ABACUS · WRITING THE RULES
Written once, checked as you write it.
Building an accounting rule step by step on top of a shared data structure, so the rule is something the software can read and reuse instead of a paragraph somebody has to interpret.
FOR THE PEOPLE WHO OWN POLICY · REUSED EVERYWHERE06 · OUTCOMES
$20Msaved every year, ongoing
90%+chose to use it within three months
650+trading relationships taken off spreadsheets
100+new businesses that could finally launch
999+outstanding requests, finally written down in one place
Where these numbers come from. Adoption and the year-over-year saving were tracked by the Finance operations team over the four quarters following launch, against the cost of the manual process plus the third-party software it replaced. Excel stayed available the whole time, so adoption here means chosen, not mandated.
The adoption number is the one I would defend first. Nobody was forced off spreadsheets — they stayed available, free and familiar for the entire rollout. So staying in the product on the last night of the month was a real choice, and people kept making it.
07 · WHERE THIS MAPS TO SENIOR SCOPE
If you’re hiring at staff or principal level.
No precedent, no competitor, no existing screen. The research is what produced the problem definition the programme was then funded against.
Three products, three audiences, one shared way of working and one shared data structure. The joins between them were the actual design work.
Accountants, product managers and engineering leads on a single shared model of the work, across three teams that had been solving it separately.
Success defined in dollars and behaviour before the work started, and measured against that definition afterwards.
I stayed in the dense payment screens and the rule-writing flows — the fiddly, unglamorous surfaces most senior designers stop looking at once a programme gets large.
Want the reasoning, the research artifacts and the screens?
↳CASE STUDY · AMAZON · FINANCE TECHNOLOGY
The Ledger, Digitized
Inside the world's most digital company, money between its own businesses still moved on paper logic: payments matched in Excel, the rules for recording them sitting in somebody's inbox. Three products changed that.
ROLEUX Lead · Product strategy
SCOPEFulcrum · ICSE · Abacus
DOMAINAccounting · Tax · Treasury
IMPACT$20M saved, every year
How much time do you have?
THE 60-SECOND READ
Manual finance operations.
One trusted platform.
650+ trading relationships between Amazon's own companies — plus every rule, payment and new business launch — depended on numbers somebody was keeping by hand.
I led the research and set how the three products — Fulcrum, ICSE and Abacus — divided the work and handed off to each other, aligning Finance, product and engineering around one system.
What people did in the first three months proved they trusted the platform under a real deadline, with the spreadsheet still one click away.
BEFORE WE START · THE SETUP
What this is, and who it was for.
Amazon is not one company. It is hundreds of separate legal ones, and they trade with each other constantly.
01 · The structure
Amazon US, Amazon Germany, AWS, Prime Video — each its own legal company, buying server capacity, advertising, shipping and devices from the others. 650+ such relationships.
02 · The obligation
Both sides record every exchange, the two records must agree exactly, then it must be paid — by a monthly deadline that never moves. Those totals become the numbers Amazon publishes.
03 · What made it unusual
None of it had ever been software. No competitor to study, no prior art, no screen to improve. I was replacing a spreadsheet, an inbox, and a policy document on somebody’s desktop.
AccountantsThe people who close the books each month. They needed to see where every payment stood, and why.
Business programme managersThe people launching new Amazon businesses, who have to tell Finance how the money will work — in language they actually speak.
Policy ownersAccountable for Amazon’s published numbers being right. They decide what may and may not be automated.
Tax and TreasuryTax works out what is owed in each country. Treasury manages the actual cash and where it sits.
Describe the business in plain terms; it works out the accounting behind it.
Every payment between two Amazon companies, on one screen, for the first time.
The accounting rules, written once, checked as they are written, and reused.
A note on the language
Accounting has the densest vocabulary of any subject on this site. Any term with a dotted underline will explain itself if you hover or tap it, and the glossary below holds all of them in one place.
THE PROBLEM
650+ trading relationships, settled by hand in Excel.
What people knew stayed in their heads, the rules lived in inboxes, and $15M+ a year went on outside software that never closed the gap — while every payment matched by hand was a chance to put a published number in error.
WHAT WAS AT STAKE
100+
New Amazon businesses waiting in line to launch, because nobody could set up their accounting fast enough.
$15M+
Spent on third-party software to paper over the gaps.
20+
Engineer-weeks lost to teams solving the same problem twice.
650+
Trading relationships between Amazon's own companies, managed by hand.
THE RESEARCH
Learning accounting before designing for it.
These processes had never been software, so there was nothing to test and nothing to copy. I led research done by observation inside real settlements, mapped every manual step, and turned what I saw into nine documented kinds of user on one shared template.
Each one captured what that person is responsible for, the words they use, what they are allowed to see and what happens if they get it wrong — not their age or job title. Those differences became the shape of the platform: the people launching businesses describe what they want, accountants inspect what actually happened, and policy owners set the rules everyone else runs on.
WHAT THE RESEARCH CHANGED
Business intent in. Governed entries out.
Observation exposed the same tension everywhere: the accounting has to be exact to the penny, but most people entering the process think and speak in ordinary business terms. I turned that tension into three product laws: translate what the business says into what accounting needs, make it possible to see where anything stands, and stop mistakes before they are live.
01 · TRANSLATE
Start in the user's language.
Fulcrum begins with the business: what is launching, how the money arrives, and who owns the decision. The accounting entries are worked out from those answers instead of demanded up front.
02 · EXPOSE
State must be inspectable.
ICSE replaced guessing-from-a-spreadsheet with the actual numbers: what is owed, which records agree and which do not, what is unusual, and a path down to the individual transaction. An accountant could finally see where a payment stood, and why.
03 · PREVENT
Move validation upstream.
JEM and Abacus check the work while somebody is still writing it. The safest error in a live financial system is the one the software will not let you submit.
ONE TRANSACTION, END TO END
One transaction. Three controlled handoffs.
Recordings come from the working prototypes, with sample data. Names and figures in them are fictional.
Money moves through finance in three steps. Something a business person can describe becomes a payment with a state you can inspect, which becomes a line in the official book of record. The screen changes at each handoff, because the person, the vocabulary and the consequences of a mistake change with it.
01 · Describe
Fulcrum captures intent
Which country, how the money comes in, who owns it, when it starts — in the language the person launching it already uses.
USSubscriptionMonthly
02 · Reconcile
ICSE exposes state
Accountants see what is owed, which records agree, what looks wrong, and the exact transaction behind every number.
Entity A$24.6mEntity B$24.6m
03 · Govern
Abacus resolves the entry
Policy owners write the rule once, and the check built into it makes the two sides of the entry come out the same way every time.
DRCRBalanced
Launching a business
FULCRUM · SETTING UP A NEW BUSINESS
Business facts in. Finished accounting out.
100+ new businesses sat waiting to launch because the business side and the accounting side literally did not speak the same language. The guided flow I designed creates one shared workspace: plain business facts go in, the accounting entries Finance needs come out, already checked.
I shaped Fulcrum around one separation: what the person knows versus what accounting has to produce. The flow translates between them, keeps a real accountant close by for anything unusual, and catches mistakes before they are live.
01Guided setup
A “tell us about the business” flow turns familiar facts into the accounting behind them.
02The JEM tool
Drag business fields onto accounting fields; anything that does not add up is flagged before it goes live.
03Comments in place
Suggestions sit on the thing being discussed, instead of in a twelve-reply email chain.
Guided setup · mapping business fields to accounting fields · comments in place
The payment itself
ICSE · PAYING EACH OTHER, VISIBLY
Every payment, visible at last.
Paying money between two Amazon legal companies was pure Excel. No screen for it existed anywhere. ICSE let accountants see individual transactions for the first time: how long each amount has been outstanding, which records agree and which do not, filters like “anything over $100k,” and every way of paying — part of it, all of it, or more than the recorded amount — in one flow.
650+TRADING RELATIONSHIPS, TAKEN OFF SPREADSHEETS
The rule, and what it produces
ABACUS · WRITING THE ACCOUNTING RULES
Policy as a product.
The rules for how to record things were written down inconsistently and enforced mostly by memory. Abacus made them structured, guided and kept in one place: a single library built on a shared data structure, so a rule is something the software can read and reuse rather than a paragraph somebody has to interpret.
Built step by step. You define what the rule covers and how it is checked, in order, instead of writing a paragraph and hoping.
One shared structure. Everything downstream reads the same definitions, so consistency is built in rather than policed.
Building a rule step by step · the shared definitions that keep everything downstream consistent
PROVEN AT MONTH-END
When the pressure rose, the platform held.
The real test was not whether people could use the platform in a demo. It was whether they would stay in it on the last night of the month, with a fixed deadline and a familiar spreadsheet one click away. We tested real payments, real accounting entries and real exceptions across all nine kinds of user, making every state easy to trace and explain out loud.
Month-end platform closeQ1
Fulcrum · setting up a businessObserved
ICSE · where the payment standsReconciled
Abacus · writing the ruleValidated
Chose it in the first quarter
90%+
Platform stateBalanced
Exceptions stayed visible under pressure.
Accountants could trace a total down to the individual transaction behind it, and people who were not engineers could write rules without having to memorise the underlying data structure.
People stayed in the product.
More than 90% chose the platform in its first three months. That mattered because its real competitor was never another product — it was the familiar escape hatch back to Excel.
Every handoff strengthened the system.
Setting up a business, tracking a payment and writing a rule now ran on one shared model. Each new relationship reused the same language, the same controls and the same source of truth.
THE PROGRAM READOUT
What the program made visible.
Synthesized from documented program outcomes. These are readouts rather than direct quotes.
Readout 01
Finance gained more than a tidier screen. What a business intends, where its money actually stands, and the rules that govern both became controllable in one place.
Readout 02
The strongest signal was what people chose. Teams stayed in the product even when deadline pressure made Excel the easiest escape.
Annual operating impact$20M
saved every year, ongoing
650+trading relationships taken off spreadsheets
999+outstanding requests, finally in one place
There are shorter versions of this same project.
THE CRAFT, UP CLOSE
One screen, and the decisions inside it.
A real shipped ICSE screen at full size: every settlement relationship between two Amazon companies, and the state of each. Click to zoom. Four of the decisions that produced it are on the right.
Click to zoom
- HierarchyThe page follows the investigation.
Summary, then filter, then the two sides, then the transactions underneath. That is the order an accountant actually works in — state first, evidence last — rather than the order the database would suggest.
- ComparisonPayable and receivable, side by side.
Reconciliation is a comparison, so the two sides are never a tab apart. Both carry a filled bar against the same scale, which turns “do these agree” into something answerable at a glance instead of by arithmetic.
- StateThe settlement decision reads as a word.
“Settle” sits in the header with an icon and a label. These screens get printed and defended in audit, so a state that exists only as a colour does not survive a photocopier or a colour-blind reviewer.
- ScaleCounts are in the headings.
“Transactions for Payable Entities (56)”, with pagination beside it. At this volume the most expensive mistake is believing you have seen everything, so the total is never more than a glance away.