Digitizing Amazon’s Financial Ledger
Challenge
Amazon's internal financial operations—specifically Accounting, Tax, and Treasury—were operating on fragmented, legacy processes. The ecosystem suffered from a reliance on manual spreadsheets and disjointed communication channels. This created significant "controllership risks" and prevented teams from operating at a granular transaction level.
Knowledge about financial products and policies was siloed; there was no central repository for accounting rules or customer artifacts
Critical processes like intercompany settlements were managed manually in Excel, leading to high latency and potential for human error
Previous tools were unintuitive, leading to low adoption rates and a continued reliance on manual workarounds
Goal
digitize and standardize the financial ecosystem. This meant building a suite of interconnected tools to handle Business Onboarding (Fulcrum), Transaction Settlement (ICSE), and Policy Management (Abacus), transforming manual workflows into secure, scalable, and accessible digital experiences.
Metrics to Consider
100+
New businesses that were in backlog to launch.
20+
SDE weeks working on duplication
$15 Million+
Spent on third party software
650+
Inter-company manual relationships to manage
Process and Research
I was productizing processes that had never been digitized before. As such, generative research was critical. I could not simply copy an existing UI; I had to understand the core accounting behaviors. This meant understanding what users were part of the process, and how they worked in the legacy system. Then figuring out a way to make sure that the new system accommodated their needs beyond what was required and made them more productive.
Day in the Life Studies
For complex workflows like settlements, I conducted observation sessions to watch accountants perform their manual jobs, mapping out their interactions with spreadsheets and legacy systems.
This meant watching as they used excel, and observing the ways in which they used different products and sometimes even watching them struggle with finding an important approval mail.
Unified Persona Architecture
I found that customer requirements were disparate across the organization. To solve this, I conducted extensive research to create a Unified Persona Template now used across the entire organization. We identified 9 key personas, including "Lisa Ann" (Business TPM), "Marla" (Accounting FBI), and "Guannan" (Local Accountant), to anchor our design decisions.
Artifacts from Data Analysis
There was a massive amount of data that was collected and then analyzed using various data analysis techniques. Those artifacts then formed the basis of designs to be tested with users.
End to End UX flow for ICSE
Information Architecture Maps created for all products.
Logic Flow
Logic Flow
Customer Journey Maps
End to End UX flow for FulcrumFulcrum
Challenge
Launching a new business initiative required bridging the gap between "Business Requirements" (what the business does) and "Accounting Requirements" (how it hits the General Ledger). This process was fragmented, leading to slow launches.
Solution
I designed Unified Flash Onboarding (UFO), a platform that connects Business TPMs with Accountants through a shared digital workspace. It allows TPMs to input revenue details and payment methods without needing to know accounting jargon
Key Features
Guided Onboarding : A "Tell us about the business" wizard allows TPMs to input revenue details and payment methods without needing to know accounting jargon
JEM Developer Tool : A visual interface for accountants to "drag and drop" Journal Entry Mappings (JEMs). I designed a validation engine that flags "Warnings" and "Unverified" mappings, preventing errors before they reach production
Collaboration Layer : To reduce email back-and-forth, I designed an inline "Suggest Changes" interface, allowing stakeholders to review configurations asynchronously
Simplified workflow for launching a new business from an accounting standpoint. The user can add business details, go through accounting rules and policies that are relevant for the business, and then test it with journal entry mappings.
Inter-Company Settlement Engine
Challenge
Settling transactions between different Amazon entities was a manual, high-risk process performed entirely in Excel. There was no UI for accountants to view, filter, or approve settlements at a transaction level
Solution
I designed the first-ever digital interface for this process, translating a multi step manual workflow into a seamless UI that allowed for managing settlements and provided transaction level granularity
Key Features
Granular Drill-Downs : Users can now view "Aged Balances" and transaction history in a "Details" view, moving them away from static spreadsheet rows to dynamic data inspection
Settlement Dashboard : A high-fidelity "Settlement List" allowing accountants to filter by criteria like "Wire > $100k" or "Matched/Unmatched" status
Ability to partial, gross, or over settle
Run through of one of the paths through the ICSE workflow
Abacus (Accounting Rule Management)
Challenge
Accounting policies were documented inconsistently, making it difficult to enforce rules across the organization. There was no standardized schema for defining business events
Requirement
I designed a unified, singular workflow management and repository for accounting policies management.
Guided Rule Creation : Designed a workflow for "Creating a new accounting rule" that guides the user through defining attributes (e.g., invoice_id) and validation logic
Schema Design : Created structured templates for defining "Business Processes," "Document Types," and "Event Types," ensuring data consistency
