Problem

Every financial number existed in the ERP. Seeing what they meant took four reports and an accountant.

Built

One screen for the money, fed by our own APIs. Plus an AI that answers questions about it.

Status

running, in-house

We’ve had proper reporting for years. Trial balance, balance sheet, cash flow statements, aging reports, any of it, any time. On paper we could see everything. And still, whenever I wanted to know how we were actually doing, I couldn’t get a straight answer out of a single screen.

The problem isn’t missing data. The problem is a translation gap. Ask an accountant how the company is doing and you get a balance sheet, because that’s the language accounting speaks. Structural, traditional, correct. But I was asking something much simpler. How much is owed to us right now. How much do we owe. Will the money coming in cover the money going out. Is our cash getting better or worse. Is anything about to go wrong. And which customer, exactly, is late.

Every piece of that lives in the ERP. It has to; that’s what an ERP is for. But ERPs are built to keep records, not to show them. So for years my picture of the company came from three or four reports, pulled at different times, compiled by hand, usually by me. My seat in the company isn’t finance. I’m one of the founders and I watch the money closely, which in practice meant the compiling kept landing on me. When a need shows up often enough, it becomes a project whether you wanted one or not.

The build was not clever and I won’t pretend it was. We listed what I actually look at, pulled it out of our own system through its APIs, and put it on one screen written in owner language instead of accounting language. Owed to us, we owe, cash and its direction, who’s late, per customer. Then the one detail that made it real: a few operators got the right to add what the system can’t know. “This one pays Thursday.” “That one always runs two weeks late, don’t panic.” A dashboard that knows what the humans know is a different animal from a dashboard that doesn’t.

Boring project. Genuinely boring. Also one of the most useful things running in this company.

Then came the part I hadn’t tried before. I started loading the financial data into an AI in the terminal and asking it questions. There’s a trust decision in that sentence, I know. I’m on the trusting side of it; you may not be, and that’s fair. But talking to your own company’s numbers is a remarkable thing. What happened this month. What drove it. What helped us, what hurt us, which way we’re drifting. And then the what-ifs, live: cut our receivable days by ten, raise prices five percent, shave two percent off material costs, and show me how each one lands. Questions that used to mean a meeting and a week of back-and-forth turn into a few minutes at a prompt.

Talking to data has never been this easy. Understanding financial data has never been this easy. I keep saying that sentence to people and they nod politely, and then I show them the screen and they stop nodding politely.

This one stays in-house too, and for once the reasoning is mostly humility. Finance isn’t my field. I don’t know how other companies handle this or whether they suffer the same way, and I can’t tell whether this would sell or even generalize. So it stays home, next to the ads manager and the lifecycle tracker. That’s three in a row now.

What I’m keeping from this one:

• The build added exactly nothing to cash flow. It changed how well I understand cash flow, completely. Some tools earn money; some tools earn clarity. Budget for both.
• Systems of record are built to store, not to show. The gap between those two verbs is where owners lose their evenings.
• The translation layer is the actual product. The data was never the problem; the language was.
• Same lesson as the last entry: we knew the process cold, so the build was short.

Built for myself first. And finally, in my own language.