Company
BILL~$290B+ annual payment throughput
Turning a reporting backlog into a centralized insights system.
BILL's Accountant Console served 700+ accounting firms, but reporting had grown as a queue of one-off features. I made the unpopular call to design one reporting framework instead of shipping twelve more disconnected reports — and led the design team that shipped it.
700+
Accounting firms on the Console
$290B+
Annual payment throughput at BILL
AP·AR·Spend
Unified under one reporting framework
1 system
Where there had been a backlog of reports
The challenge
Reporting had become a backlog, not a product.
Accounting firms use the Console to run their clients' books across payables, receivables, and spend. Every time a firm asked for a way to see something, the answer had been the same: ship another report. Over time that produced a growing library of one-off reports that each solved one request but never added up to a way of understanding a client's financial picture.
The business framed the next step as "more reports." The real problem was that firms didn't need more reports — they needed the reports they had to become a system they could reason with. Naming that gap, and getting the org to fund it, was the design work before any pixels.
Why it was hard
Platform-scale constraints, not a blank canvas.
01
Many firm sizes, one surface
A two-person practice and a 200-seat firm both live in the same Console. A framework had to serve the small firm without starving the large one.
02
A backlog with momentum
Shipping one more report was the path of least resistance and had real internal support. Proposing a framework meant arguing against the roadmap everyone already believed in.
03
Financial-grade reliability
At $290B+ in throughput, reporting isn't decorative — firms make client decisions on it. New structure could not introduce ambiguity into numbers people trust.
04
Cross-functional, not solo
The call touched PM priorities, engineering sequencing, and a design team's workload. Getting it shipped was as much alignment as it was craft.
What I led
Where I set direction, and where I shipped.
Honest about the difference between what I personally produced, what I directed, and what the team delivered together.
I personally produced
- The reporting framework — the model that made AP, AR, and Spend one system
- The core information architecture and reporting patterns
- The argument, artifacts, and demos that reframed "more reports" as "one system"
I directed
- The design team's work against the framework as it scaled
- Sequencing: framework and highest-frequency needs before polish
- Design quality and consistency across the surfaces that shipped
I influenced
- The roadmap decision to fund a framework over another batch of reports
- How PM and engineering scoped the first release
- How the org talks about reporting work to this day
The team delivered
- Production build across the reporting surfaces
- Engineering the data and performance behind the views
- The shipped Console experience firms use today
Key decisions
The decision ledger.
The calls that shaped the outcome — with the alternatives, the tradeoff, and what I'd revisit now.
The decision
Stop treating reporting as a request queue. Design a single framework that AP, AR, and Spend reporting all live inside, so new needs extend a system instead of adding another island.
Alternatives considered
Keep shipping individual reports (fast, popular, compounding debt). Build a heavy BI/report-builder (powerful, but a new product to learn).
Evidence
The existing library kept growing without making firms' work easier — the pattern of one-off requests was itself the signal.
Tradeoff accepted
Slower to first ship, and a harder internal sell, in exchange for a surface that compounds instead of fragmenting.
Who was involved
Design (led), PM (priorities), engineering (feasibility & sequencing), leadership (funding the reframe).
Result
One insights system replaced the backlog — and the framing changed how the org talks about reporting work.
What I'd change now
Bring the highest-volume firms into the framing earlier with a lightweight prototype, to shorten the "is this worth it" debate.
The decision
Anchor the framework on the firm workflow where poor reporting caused the most real pain, and make sure the model scaled up rather than designing for an abstract "average" firm.
Alternatives considered
Design for the median firm (safe, blunt). Design for the largest firms first (powerful, but risks over-building for the few).
Evidence
Firm workflows differ sharply by size; the sharpest pain concentrated where reporting volume and client load were highest.
Tradeoff accepted
A more opinionated first cut, in exchange for a framework grounded in a real workflow instead of a lowest-common-denominator one.
Who was involved
Design (led), PM, and firm-facing partners who understood the workflows.
Result
A framework that held up as it scaled across the range of firms on the Console.
What I'd change now
Instrument the "hurts most" workflow with clearer before/after measures up front, so the payoff is provable, not just observable.
The decision
Get the structural model right and shipped before investing in high-fidelity polish, so the team wasn't perfecting the surface of the wrong shape.
Alternatives considered
Polish each report as it shipped (feels productive, entrenches the wrong structure).
Evidence
Polish applied to a fragmented structure would have made the fragmentation harder to undo later.
Tradeoff accepted
Less immediate visual wow, in exchange for a structure worth polishing.
Who was involved
Design team (directed), with PM and engineering on sequencing.
Result
The team spent its craft on a system that would last, not on decorating a backlog.
What I'd change now
Pair the framework release with one flagship polished view, to make the vision legible to stakeholders sooner.
Collaboration & leadership
Leading as a player-coach.
The hardest part of this project wasn't the interface — it was getting an organization that believed in "more reports" to fund a framework instead. I did that by making the alternative concrete: artifacts and demos that let people feel the difference between a backlog and a system, rather than argue about it in the abstract.
With engineering, I framed the first release around the highest-frequency reporting need so we shipped something real without a new permissions model. With the design team, I set the direction and the quality bar, then stayed in the work — reviewing, unblocking, and shipping alongside them rather than handing off a spec. That's the mode I lead in: set the direction, hold the standard, and still ship the pixels.
Product evolution
From a queue of reports to one surface.
Before — a growing library of one-off reports
Each firm request produced a new, standalone report. Useful individually, but they never composed into a way of understanding a client.
Report request→
New one-off report→
Another request→
Another report…
After — one insights framework across AP, AR & Spend
New needs extend a shared model instead of spawning islands. Firms reason across payables, receivables, and spend in one coherent surface.
Firm need→
Extends the framework→
Consistent, connected view→
One system that compounds
Loading interactive prototype…
Interactive recreation of the Reports experience, rebuilt for this portfolio — not a live production screenshot.
Outcome
What changed.
A system, not a backlog
AP, AR, and Spend reporting became one framework across 700+ firms — new needs now extend it instead of fragmenting it.
Firms reason, not just retrieve
Reporting shifted from pulling isolated numbers to understanding a client's financial picture in one place.
The org's language changed
"Ship another report" gave way to "does this fit the system" — a durable shift in how reporting work is scoped.
A framework built to scale
The model held from the smallest practices to the largest firms on the Console, at financial-grade reliability.
Precise adoption and efficiency figures for this initiative are being confirmed before they're published here, rather than estimated.
Reflection
What I took from it.
What worked
Reframing the problem before touching the UI. The framework only got funded because the alternative was made tangible, not argued.
What I'd do differently
Instrument the outcome earlier. The impact was real; the measurement should have been designed in from day one.
What I learned
At platform scale, the highest-leverage design act is often naming the real problem — and giving the org the confidence to fund the harder, better path.
How it shaped my leadership
It's why I lead as a player-coach: the person setting direction should be close enough to the work to prove the direction is right.
More of this — for your team?
I lead design that connects craft to business outcomes, and I still ship. If that's the kind of leader you're hiring, let's talk.