Spreadsheets handle a startup's books just fine — right up until they don't. The breaking points are remarkably consistent. Almost every finance team hits the same three walls in the same order: prepaids, accruals, and allocations. They're the first schedules that stop being a tab you glance at and start being a system you maintain.
Here's why each one breaks, and what it looks like when the logic lives in the ledger instead of beside it.
1. Prepaids — the schedule that won't stay current
You pay a year of insurance in January. The expense belongs across twelve months, so you build an amortization schedule: one row per month, a formula that spreads the cost, a reminder to book a twelfth every period. It works. Then you add the annual software contracts, the prepaid rent, the deposit that amortizes over the lease — and now you're maintaining a dozen schedules, each needing a manual entry every month, each quietly wrong the moment a contract is cancelled mid-term.
The problem isn't the math. It's that the schedule and the books are two separate things you keep in sync by hand. Edit the schedule and you still have to remember to repost. Cancel early and you have to unwind it correctly.
Amortization schedules that live in the ledger post their own entries. The waterfall is always current because it is the books.
When a prepaid lives in Granite, the schedule is part of the accounting system. Entries post automatically. Edit a schedule and it voids and reposts correctly. The waterfall across every prepaid is one report, not a tab you hope is up to date.
2. Accruals — the entry you have to remember to reverse
The December cloud bill arrives in January, but the expense is December's. So you accrue it: book it into December, then reverse it in January when the real invoice lands. Simple — except the reversal depends entirely on someone remembering. Miss it, and you've double-counted. Track it in a side sheet, and now you have a second list to police every close.
- The reversal date is set when the accrual is created — it's part of the entry, not a note in a tracker.
- Due reversals surface during close, so nothing depends on memory.
- If the invoice still hasn't arrived, you extend — with full history of the original, the reversal, and every extension.
The accrual carries its own reversal. The books reflect reality without a separate tracking sheet shadowing them.
3. Allocations — the rule you re-key every period
One rent payment, three departments. A shared software bill split by headcount. A founder's time across two cost centers. Allocations start as a single formula and metastasize into a model — and every period you re-run it, re-key the splits, and hope the ratios still match reality after the last reorg.
Allocations are logic, so they should be a rule, not a monthly retype. Define how a shared expense splits once — by percentage, fixed amount, or ratio — and match it by vendor, account, or both. The allocation applies itself every period, you preview before posting, and adjustments carry a proper audit trail.
The through-line
Notice what these three have in common. None is mathematically hard. Each breaks for the same reason: the logic lives in a spreadsheet that can't post entries, can't remember a date, and can't apply itself. The fix isn't a better spreadsheet. It's moving the logic into the ledger so it stops being something you maintain and starts being something the system holds.
That's the whole idea behind Granite's subledgers: prepaids, accruals, and allocations as real parts of your accounting system — not tabs you update in parallel and pray you didn't miss.