Uber

Redesigning Uber's journal entry automation to turn a five-month engineering dependency into self-serve control

Redesigning Uber's journal entry automation to turn a five-month engineering dependency into self-serve control

Due to my NDA, I can't share actual imagery, data, or volumes from this project. What you see here is recreated for illustration — the strategy, design thinking, and decision-making logic stay true to the original work.

Due to my NDA, I can't share actual imagery, data, or volumes from this project. What you see here is recreated for illustration — the strategy, design thinking, and decision-making logic stay true to the original work.

Impact

Turnaround

Automation

Automation

Time cut from months down to weeks

Time cut from months down to weeks

Autonomy

Dependency

Dependency

Removes dependency on specialized engineering and data teams for routine automation and fixes

Removes dependency on specialized engineering and data teams for routine automation and fixes

Governance

Tracking control

Tracking control

Every onboarding logged with an approval trail in one central tool

Every onboarding logged with an approval trail in one central tool

Overview & problem

Journal entry automation, reimagined — from months of engineering dependency to weeks of self-serve control

Journal entry automation, reimagined — from months of engineering dependency to weeks of self-serve control

Automating a single journal entry took about five months — requirements, development, testing, fixes, and rollout, with issue resolution alone eating the largest share of that time. I built a self-serve tool that lets accountants define computation and posting logic themselves, without engineering or data science in the loop.

Success meant faster automation — weeks, not months — with fewer dependencies on engineering and data science, and enough agility to adapt as processes changed. It also meant better accuracy than manual entry, stronger controls with every entry tracked and approved, and all of it stored in one accessible, centralized data source.

Insights

One root cause — automation lived outside the team that needed it

One root cause — automation lived outside the team that needed it

Months to automate one entry

Requirements, development, testing, fixes, and rollout — with issue resolution alone eating the largest share of that timeline.

No way to self-correct

The accounting team can't diagnose or fix errors in automated entries — any adjustment means weeks of turnaround through specialized technical teams.

Bottlenecked scale

Dependency on engineering and data science limits how many entries can realistically get automated before financial close deadlines.

Build the right thing

How might we give accountants the power to build and fix their own automations — without needing an engineering queue?

How might we give accountants the power to build and fix their own automations — without needing an engineering queue?

User feedback

50%

felt overwhelmed by the flow's context, all shown at once.

User feedback

67%

wanted the flow divided into clear steps.

Testing

User testing showed one clear signal — break things it up

User testing showed one clear signal — break things it up

I ran 7 1:1 usability sessions with accounting stakeholders, alongside the PM, to stress-test the new guide creation flow. The takeaway was consistent — the flow packed too much into one view.

Iterations & explorational phase

Getting from finding to fix took several passes

Getting from finding to fix took several passes

The base amount step alone went through several iterations — narrowing the source-data picker, reworking how filters and recurrence stacked together, and simplifying the accounting treatment screen once testing showed preparers were losing track of which fields still needed input.

Logic mapping

The standard flow the hypothesis bet on

The standard flow the hypothesis bet on

I mapped every entry to one of two paths — accrual or allocation — since that single question decides everything downstream: which fields apply, how the amount gets prorated, and whether it needs a location split. Rather than build separate logic for each entry type, I designed one decision tree both paths run through, ending in the same GL posting step.

AI demo

Vibe coded prototype

Vibe coded prototype

I used AI-assisted tooling to prototype the actual interactions — the five-step rule setup, the filter builder logic, and the UAT test run — so you can click through it instead of judging it from static screens alone. It's a prototype, not production code, but the logic mirrors the real design decisions.

Work

From spreadsheet to self-serve rule engine

Operations Hub turns a manual journal entry process into a guided workflow. Preparers configure a recurring entry rule once, test it against real data, and send it for review. Reviewers approve or reject it from the same place.

Dashboard — one place for every entry rule

  • Every rule lives in one table — type, frequency, status, requestor, and approver, all visible without opening anything

  • Filters narrow the list down in a couple of clicks

  • Rules waiting on a decision open straight into review from the row menu

Guided onboarding — a five-step flow instead of a blank form

• Rule setup splits into five steps — definition, base amount, transformation, accounting treatment, and UAT

  • A progress rail shows exactly where you are and what's already done

  • Any finished step stays editable — no restarting to fix an earlier answer

Filter builder — defining the base amount without writing a query

• Preparers build the source-data query from conditions and nested groups, joined by AND or OR — no query language required

  • A connector line down the side keeps the logic readable as it grows

  • Turns what used to be a manual data pull into something a preparer can build themselves

3 entry types, 1 flow — allocation, accrual, and reclass share the same flow

• Steps 3 and 4 adapt automatically to the entry type chosen in step 1

  • Allocation splits amounts across lines of business; accrual adds proration schedules, fixed-percentage distributions, and nested LOB + LOC splits

  • Reclass — the simplest case — comes down to a single choice, instead of forcing every entry type through the same heavy flow

Review and approval — a clear decision for the reviewer

• Reviewers open a pending rule in read-only mode and walk through the same five steps the preparer did

  • Approving takes one click, with an optional comment

  • Rejecting requires a reason, so the preparer knows exactly what to fix — no guessing

Guardrails — errors caught before they reach the ledger

• The flow won't advance while a required field is blank

  • A banner explains what's missing, and every blank field is marked inline

  • Allocations are checked to total 100% automatically, and pre-filled dropdowns never throw an error

Dashboard — one place for every entry rule

  • Every rule lives in one table — type, frequency, status, requestor, and approver, all visible without opening anything

  • Filters narrow the list down in a couple of clicks

  • Rules waiting on a decision open straight into review from the row menu

Guided onboarding — a five-step flow instead of a blank form

• Rule setup splits into five steps — definition, base amount, transformation, accounting treatment, and UAT

  • A progress rail shows exactly where you are and what's already done

  • Any finished step stays editable — no restarting to fix an earlier answer

Filter builder — defining the base amount without writing a query

• Preparers build the source-data query from conditions and nested groups, joined by AND or OR — no query language required

  • A connector line down the side keeps the logic readable as it grows

  • Turns what used to be a manual data pull into something a preparer can build themselves

3 entry types, 1 flow — allocation, accrual, and reclass share the same flow

• Steps 3 and 4 adapt automatically to the entry type chosen in step 1

  • Allocation splits amounts across lines of business; accrual adds proration schedules, fixed-percentage distributions, and nested LOB + LOC splits

  • Reclass — the simplest case — comes down to a single choice, instead of forcing every entry type through the same heavy flow

Review and approval — a clear decision for the reviewer

• Reviewers open a pending rule in read-only mode and walk through the same five steps the preparer did

  • Approving takes one click, with an optional comment

  • Rejecting requires a reason, so the preparer knows exactly what to fix — no guessing

Guardrails — errors caught before they reach the ledger

• The flow won't advance while a required field is blank

  • A banner explains what's missing, and every blank field is marked inline

  • Allocations are checked to total 100% automatically, and pre-filled dropdowns never throw an error

Retrospective

Why this project mattered

Why this project mattered

The $2M funding outcome wasn't just a business result — it was confirmation that the design decisions translated into real-world confidence. Investors don't fund products they don't trust. That was the most direct feedback I've ever received on design quality.

This isn't just a faster form — it's expected to change who owns the financial close. Once live, accountants build, test, and adjust their own automations in the same afternoon, instead of filing a ticket and waiting weeks. That turns a five-month, four-team dependency into something one team runs on its own, freeing engineering and data science for the problems only they can solve.