By month eighteen a typical startup has a bank, a card, a payroll system, a payment processor and some accounting software. Nobody chose that stack. It accumulated, one urgent problem at a time, and each tool works fine on its own.
The mess is never in the tools. It is in the seams. Deel does not know what Mercury holds. Ramp does not know a Stripe payout landed. Every one of those systems pushes data into your ledger and none of them pushes data to each other, which means the only place the whole company exists as one picture is the ledger, and the ledger is the piece founders set up last and think about least.
The short version
- Five layers: bank, cards, payroll, processor, ledger. The tools are interchangeable, the layers are not.
- Set them up in that order. The ledger should be chosen by your first payroll run, not at year end.
- The tools integrate with your ledger, not with each other. Nothing reconciles itself.
- The two things that break first: contractor payments landing as one lump, and Stripe payouts booked as revenue.
- Before adding any tool, ask what it pushes into the ledger and who checks that it arrived.
The five layers, and what each one owes the ledger
Bank. Mercury, Brex, or a traditional business account. It owes the ledger a clean, uninterrupted transaction feed with real merchant descriptors. What it does not owe you is meaning: a $14,000 outbound wire is a wire, and whether it is a contractor, a vendor prepayment or a treasury transfer is not in the feed.
Cards. Ramp, Brex, Amex or Chase. It owes the ledger structured merchant and receipt data, ideally per employee and per vendor. This layer is where clean data is cheapest to get, because a card platform can enforce receipt capture at the moment of spend, which is the only moment anyone remembers what a charge was for.
Payroll and contractors. Gusto, Rippling, Deel. It owes the ledger a split: gross wages, employer taxes, benefits and fees as separate lines, per person and per department. This is the layer that most often arrives as one number and should not.
Processor. Stripe. It owes the ledger four separate things that arrive as one stream: gross revenue, processing fees, refunds and chargebacks, and payouts. Payouts are transfers, never revenue.
Ledger. Where the other four land and become a P&L, a balance sheet and a cash flow statement. It owes you the truth, and it can only do that if the other four are connected and someone owns the exceptions.
The wiring order, and why it is that order
Bank first. Everything settles somewhere. Open the account, and open a second one at a different institution while you are thinking about it.
Payroll second. It has legal deadlines and penalties that accrue per quarter, which makes it the layer with the least tolerance for improvisation. It also determines your state registrations, which take days to weeks and cannot be rushed when a hire starts Monday.
Cards third. Spend controls are cheap to add before there is spend and painful to retrofit across forty existing vendor relationships. A card per vendor with a cap that matches the contract is a ten-minute setup that prevents a category of month-end surprise.
Processor when you start charging. Nothing to do before revenue exists.
The ledger no later than the first payroll run. This is the one founders defer, and deferring it is the expensive choice. Backfilling six months of categorization across four systems means reconstructing intent from bank descriptors, which is exactly the work that produces a $31,000 unexplained difference in diligence.
Where the data actually breaks
Three failures account for most of the damage, and all three are silent.
Contractor payments arriving as one lump. Deel or a similar platform debits your bank once for a batch. In the bank feed that is a single line: one date, one amount, one descriptor. Without the payroll system connected properly to the ledger, the entire batch lands in one account with no split by person, project or class. Six months later you cannot answer what the machine learning contractor cost versus the design contractor, which means you cannot compute R&D credit eligibility, defend gross margin, or price anything.
Stripe payouts booked as revenue. A payout moves money you already earned from the Stripe balance to your bank. Recording it as revenue counts the sale twice and hides the processing fee. It flatters revenue and margin simultaneously, which is why nobody catches it internally, and it holds until someone ties your books to your Stripe dashboard in diligence.
Transfers counted as activity. Moving $500,000 from operating to treasury is not spend and not income. It is one asset moving to another. Automated categorization gets this wrong regularly, and a single misclassified treasury transfer can make a month look like a catastrophe or a windfall.
None of these announce themselves. There is no error message. The books simply become wrong in a direction that is hard to notice and expensive to unwind.
The class dimension nobody sets up early
Every transaction should carry a class or department from the first month. Not eventually. From the first month.
Class tracking is what turns a P&L into an answer. Without it you know you spent $180,000 last quarter. With it you know that $94,000 of it was R&D, which matters for the credit, and $41,000 was sales and marketing, which matters for whether your CAC is defensible.
Retrofitting classes is genuinely awful work. It means re-deciding hundreds of transactions from descriptors alone, months after the context is gone and often after the person who made the charge has left. Setting them up on day one costs an afternoon.
At Median every entry carries a class from the start, and where the class cannot be evidenced from a document or from precedent in the client's own books, the item gets parked and the specific missing document named rather than guessed at. That rule exists because guessing produces a number that looks complete and is not.
Frequently asked questions
What does a startup finance stack actually consist of? Bank, cards, payroll, processor, ledger. Five layers. The tools within each are interchangeable; the layers are not.
In what order should a founder set up finance tools? Bank, payroll, cards, processor. The ledger connects to all four and should be chosen no later than the first payroll run.
Do these tools integrate with each other automatically? They integrate with your accounting system, not with each other. The ledger is the only place the full picture exists.
What breaks first in a startup finance stack? Contractor payments landing as one lump with no split, and Stripe payouts booked as revenue. Both are silent and both compound monthly.
How many tools is too many? The count matters less than whether anyone owns the seams. Five connected tools with an accountable owner beat three unconnected ones.
The setup checklist
- List every system that touches money at your company. Most founders find one or two they forgot.
- For each, confirm it has a live connection into your ledger and check the last date data actually arrived. A connection that broke in March is not a connection.
- Open your P&L and find the contractor line. If it is one number, your payroll system is not properly connected.
- Find how payouts are coded. If they hit revenue, fix it this month; it affects every month this year.
- Turn on class tracking now, whatever "now" costs. It never gets cheaper.
For the tools that sit at the ledger layer, see AI bookkeeping tools compared, and for the card layer, Ramp vs Amex vs Chase.
See how Median connects the whole stack and keeps the ledger current every business day.