The report arrives on the 20th: how to get yesterday's numbers without hiring a data team

The day you find out how the month went, the month is already over

There’s a scene that repeats in thousands of companies, always the same. It’s the 18th, the 19th, sometimes the 20th of the month. The file finally arrives: the sales report for the previous month. You open it, you look at it, and in the best case you discover it went as you thought. In the worst case you discover that a product stopped selling, that an important customer slowed down, that a channel collapsed — three weeks ago. Now you know. But it’s late: the month is closed, and the new one is already halfway through.

The late sales report is not an admin annoyance. It’s a tax on the speed of your decisions. Every day that passes between “something happened” and “I noticed” is a day in which you didn’t course-correct, didn’t call that customer back, didn’t stop that discount, didn’t reorder that product that was moving. And the most frustrating thing is that almost always it isn’t anyone’s fault: it’s the fault of how the report gets made.

This article is for whoever waits for the controller’s file — internal or external — to know how the company is doing. I’ll tell you two things they usually don’t tell you. The first: the problem is not the person who compiles the report, and replacing them or pairing them with a junior doesn’t solve it. The second: the solution is not “more reporting”, it’s a product that holds the sources together and gives you yesterday’s numbers without anyone opening an Excel in the morning. Let’s see why, and what you actually need.

Deciding well into the month is deciding on the past

Let’s do a thought experiment. Imagine driving looking only in the rear-view mirror, with a twenty-day delay: you see the road from three weeks ago. As long as the road is straight, everything is fine. But the moment there’s a curve — a drop, a spike, a problem — you notice when you’re already in it. That’s what it means to take commercial decisions on last month’s report.

The cost isn’t theoretical, it’s made of concrete missed chances:

A product that accelerates and you don’t reorder in time: lost sales that don’t come back, because the customer in the meantime bought elsewhere.
A product that slows down and you keep reordering as before: capital tied up, maybe ending up in clearance at zero margin.
A regular customer who stops ordering: if you notice at month-end, the recovery call arrives when they’ve already chosen another supplier.
A discount or a promo that isn’t working and that keeps running for weeks, burning margin, because the data that would say so arrives too late.

None of these lines ends up in accounting labelled “decided late”. They disappear into the noise, and next year they repeat. But added up, they’re worth far more than it costs to fix the problem at the root. The whole point of speed is this: you don’t need to know everything, you need to know it in time to do something with it. A perfect figure that arrives on the 20th is worth less than a “good enough” figure that arrives every morning.

If this sounds familiar, you probably also live with the sibling of this problem: numbers that aren’t only late, but scattered across six different tools. I’ve written about that at length in the article on how to decide when the numbers are in six tools; here we focus on time, not on dispersion.

What a day of delay is worth (a sum you can redo)

Let’s try to put a number on speed, because “delay” looks free and it isn’t. Take your monthly revenue and divide it by working days: that’s what passes through your hands every day. Now imagine that a decision taken twenty days earlier — stopping a discount that isn’t working, calling back a customer who’s slowing down, reordering a product that’s moving — shifts even just 1–2% of that flow.

On a company that does, say, 200,000 € a month, a 2% recovered on a few episodes a year is tens of thousands of euro. It isn’t a promise of results: it’s the order of magnitude of what’s at stake. The delay doesn’t cost “the time of the report”. It costs the decisions you couldn’t take in time. And the uncomfortable part is that you never see this cost, because a missed chance doesn’t leave a line in accounting: it only leaves a lower number than it could have been. It’s the same reason why daily KPIs are worth more than a perfect monthly report: not because they’re more precise, but because they arrive when you can still do something with them.

What’s really behind a “manual” report

Here comes misunderstanding number one. “The report is late because it takes time to make it.” True, but why does it take time? Because behind that file there isn’t a tool: there’s a person. A capable person, often, who every month does by hand a chain of operations nobody sees:

Downloads the data from the ERP/gestionale (and waits for the office to have closed the month).
Exports the orders from the e-commerce, in another format.
Goes to get the agents’ data, which arrives by email in spreadsheets each made their own way.
Pastes everything into a master sheet, fixes the columns that don’t match, corrects the duplicates.
Manually removes the returns, adjusts IVA/VAT where needed, fixes customer names written five different ways.
Builds the tables and the charts, lays them out, writes a couple of lines of comment.
Sends the file.

The report is late not because the person is slow, but because every month they redo the same work from scratch, by hand, on sources that don’t talk to each other. And there’s a problem more serious than the delay: fragility. That process lives in one person’s head. When they’re on holiday, the report skips. When they change job, the “how it’s done” leaves with them. When they get a copy-paste wrong — it happens, we’re human — the number is wrong and nobody notices, because there’s no automatic check that says “attention, this month doesn’t add up”.

So the real cost of the manual report is double: the hours the person puts into it (which they could use to think instead of to compile) and the risk that everything depends on them. That’s why the solution isn’t “do it faster” or “work more”. It’s taking the repetitive work off the person and giving it to a pipeline that does it on its own, every night, always the same.

A typical day of whoever “does the numbers”

It’s worth looking closely at what actually happens, because it helps you understand that the problem isn’t anyone’s laziness. The admin lead — call them what you want — waits for the office to have closed the month, then starts. Opens the ERP/gestionale, exports, waits. Opens the inbox where the agents send their sheets: one has arrived, two haven’t, one is in a different format from usual. Writes a reminder to chase them.

Meanwhile they fix the e-commerce duplicates, remove the returns by hand, notice that a customer is written three different ways and merge them. Mid-afternoon the master sheet starts to take shape; the next day they lay it out, add the charts, write a couple of lines of comment. If in the middle someone asks them for something else — and it always happens — the report slips a day.

It isn’t slowness: it’s that every month they redo from scratch a job that no system does in their place, on sources that don’t talk to each other. And the day they’re on holiday, simply, the report doesn’t come out. Keep this scene in mind: it’s the same one we find again when the numbers, besides being late, are also scattered across six different tools.

Hiring a junior analyst doesn’t fix the sources

The instinctive reaction, when the report is always late, is: “let’s hire someone to take care of it”. A junior data analyst, maybe an external data analyst by the day, someone who “puts the numbers in order”. It’s an understandable move and it’s almost always a waste. I’ll explain why.

The problem isn’t a lack of hands. It’s a lack of a system. If the sources are dirty and don’t agree, the person you hire spends the first month — and often the second — doing exactly what admin was already doing: cleaning, pasting, reconciling. Only now you pay them more. They never get to the “insight” part, because they’re buried in the “cleaning” part. And above all: when they leave (juniors move), the problem comes back identical, because the knowledge was in their head, not in the system.

Let’s put it in a table, with honest numbers declared as estimates, because the comparison matters.

	Hiring a junior analyst	Building a pipeline + product
First-year cost	~30,000–40,000 € (gross salary / RAL + contributions + desk)	one-off project + maintenance
When it delivers value	after months, if they survive the cleaning	from the first weeks, then every day
What it produces	still a report, maybe nicer	a dashboard that updates itself
If the person leaves	you start from zero	the system stays and works
Dirty sources	they clean them by hand, every time	the cleaning rules are written in the code
Key risk	dependence on one person	maintenance (who keeps the system alive)

Careful: I’m not saying “never hire”. I’m saying do it in the right order. First you build the system that cleans the sources and produces the numbers on its own; then, if needed, a person watches over it and reasons on top of it — and finally does the analyst job, not the compiler job. Hiring before you have the system is like hiring a driver for a car you haven’t bought yet. It’s the same argument, flipped, as when hiring a data analyst isn’t enough because the KPIs stay a fight: the person alone doesn’t fix what’s broken upstream.

The product: updates and alarms, not forty slides

So what do you need instead of the late monthly report? Not “more reporting”. A product, and a product does three things the file of the 20th will never do.

First: it updates itself. Overnight, a pipeline takes the data from the sources, cleans it with the rules you’ve decided, and puts it in one place. In the morning the numbers are already ready. Nobody “does the report”: the report no longer exists as an activity, it exists as an always-updated state. That’s the heart of automated business reporting: not a faster file, but the absence of the file.

Second: it talks to you, it doesn’t bury you. A forty-slide report is an elegant way to make nobody decide anything. A product shows a few numbers that matter — the four questions: are we selling enough, are we collecting, what is changing, where — and above all it sends you an alarm when something is anomalous. “Sales of product X are at −40% for three days.” “Customer Y hasn’t ordered in two weeks.” “This store is 25% below the same period.” You don’t have to remember to look: it’s the system that calls you when it’s needed. That’s the difference between useful daily KPIs and a dashboard nobody opens.

Third: it’s live, not photographed. The report is a photograph of a moment; when you read it it’s already old. The product is a window always open: you open the phone at 8, you see yesterday, you see the month up to yesterday compared with the same period before, and you decide. If you want, you go into the detail; but the point is the first screen, the one that in twenty seconds tells you whether to stay calm or pick up the phone.

The important thing to understand, as a buyer, is that “updated every night” is almost always more than enough. “Real time to the second” costs a lot more and is useful to very few: if someone proposes it as standard, ask why. To decide, yesterday’s numbers are a huge step forward compared with last month’s numbers.

Automated reporting doesn’t mean “the AI does everything”

There’s a misunderstanding to clear up, because it generates wrong expectations in both directions. Automating reporting doesn’t mean “putting AI to do the numbers”. The part that counts — connecting the sources, applying the definitions, calculating the totals, triggering the alarm when a value leaves the norm — is deterministic: they’re rules, not magic. They have to be exact, and a language model that “more or less” adds up the sales is exactly what you don’t want near your numbers.

AI, if anything, comes in at the edges: summarising in a sentence how the week went, grouping the sales reps’ notes, writing in readable Italian a comment on top of numbers already calculated correctly. But the number is done by the code, with verifiable rules, not by a model that “seems plausible”. Whoever sells you “the AI that does your reports” and never talks about sources and definitions is selling you the spectacular part and skipping the one that makes the numbers true. Trust in a dashboard is built on the boredom of the rules, not on the enthusiasm of the model.

The report that comes looking for you: alarms, not searches

There’s a subtle but huge difference between a report you have to open and a system that comes looking for you. The report, even the automatic one, assumes that someone remembers to look at it. And memory is the first thing that drops when the company is running: the intense week is precisely the one in which nobody opens the dashboard, and it’s also the one in which the things you should see happen.

A data product done well flips the logic: instead of waiting for you to query it, it sends you a signal when there’s something to know. A few concrete examples of a useful alarm:

“Sales of product X are at −40% compared with the average of the last four weeks.”
“Customer Y, who ordered every two weeks, hasn’t ordered in 20 days.”
“This branch is 25% below the same period last month.”
“Yesterday collections are at zero: possible technical problem on the online channel.”

The last example matters: a good alarm system isn’t only for seeing business drops, but also for catching the faults in the data itself. A channel that stops reporting sales often isn’t a commercial collapse: it’s an integration that broke. Without an alarm, you discover both things too late. With the alarm, you get a message in the morning and you act the same day. That’s the shift from reporting (I produce, you read if you remember) to product (the system alerts you when it’s needed).

A typical case: from the report of the 20th to yesterday’s numbers

A typical profile, architectural, no names and no invented revenues. A services company with three revenue lines and a network of sellers. Before: the report arrived between the 18th and the 22nd, it was done by hand by an external controller, and the owner “felt” how things were going by talking to the sales reps — only to discover at month-close that a line had been dropping for weeks.

What was done. First the definitions: what is a sale for each of the three lines, how reversals are treated. Then the pipeline: every night the sources flow into one place, with a check that flags if a source hasn’t arrived. Then the screen: four numbers, the comparison with the same period of the previous month, and three alarms (line below threshold, customer stalled, seller dropping).

After: the owner looks at yesterday’s numbers every morning from the phone; the controller no longer spends three days compiling, but a couple of hours a month validating and commenting; and the drops are seen after days, not after weeks. The value wasn’t “the dashboard”: it was shortening the distance between a problem and the reaction. With an honest note: the first month brought out that one of the three lines, considered “healthy”, was actually holding up only thanks to two customers. Uncomfortable to see, valuable to know — and it’s typical, because a real dashboard every now and then gives you bad news in time to fix it.

What must be true in the data (or you only build a faster delay)

Here’s the part almost nobody faces, and it’s the reason so many automated reporting projects fail: if you automate dirty data, you only get wrong numbers faster. Before you speed things up, you have to agree what the words mean. It looks trivial, it isn’t.

Take three words you use every day:

Sale. Is it the order received, the invoice issued or the payment that arrived? If sales counts the orders and admin counts the invoices, you’ll always have two different numbers for “how much we sold”, and you’ll spend meetings arguing instead of deciding.
Return. When do you take it off: from the month the product was sold or from the month it came back? The choice changes the numbers of both months, and it has to be made once and for all.
IVA/VAT. Are your sales numbers with or without IVA/VAT? It seems obvious, but half the arguments about “we did 40,000” are born here, because someone counts it and someone doesn’t.

The solution isn’t technological, it’s a decision put in writing and signed: “In our system, sale = invoice issued, IVA/VAT excluded, return deducted on the order date.” Done. From that moment there is one number, and whoever disagrees argues the definition, not the chart. This document — a few lines, not a treatise — is the most valuable piece of the whole project, because it’s the one that makes the numbers trusted. A fast dashboard you don’t trust is as useless as a slow report.

This is also why a serious project starts from here and not from the colours. If a vendor proposes to “connect everything and build you the dashboard” without ever asking how you define a sale, they’re building a faster delay, not a product.

The three words above are the most common, but not the only ones. Sooner or later these arrive too. Active customer: after how many days without orders does someone stop being “active”? The threshold completely changes the number of customers you’re “losing”. Margin: do you calculate it on list price, on the discounted net, including or not shipping and commissions? Two identical companies can declare two different “margins” only because of how they define them. None of these has a universally right answer: it has your answer, which has to be decided and written. The definitions document grows like that, one line at a time, and every line is an argument resolved forever.

How long it actually takes

No magic number, but honest ranges for an SME with the typical sources (ERP/gestionale, e-commerce, agents, bank).

Phase	What happens	Indicative time
Definitions & sources	we write what counts as sale/return/IVA, we map accesses	1–2 weeks
Data pipeline	we connect the sources, clean, build the history, put the alarms	3–5 weeks
Screen & alarms	the dashboard that opens in 20 seconds, first desktop then mobile	2–3 weeks
Bedding-in	you actually use it, we adjust definitions and views to what you need	3–4 weeks

In practice: from a useful dashboard in 6–8 weeks, to a bedded-in product in three–four months. Whoever promises you “in a week you have everything” is selling you the screen skipping the definitions and the pipeline — that is, skipping the only two parts that make the numbers true. That’s exactly why that dashboard then ends up in a drawer: beautiful, fast, and wrong.

One thing that helps you accept these weeks: a good part of the work is done in parallel with your normal activity, without stopping anything. The old report keeps coming out until the new dashboard is reliable; it only gets switched off when you trust the new numbers. It isn’t a “big bang” where on a Monday you unplug everything and hope: it’s a gradual passage, with a period in which the two worlds coexist and you compare them. It’s the honest way to do it, and also the least risky.

Reports die if nobody owns them

A common mistake is thinking that, once automated, reporting “runs on its own forever”. It isn’t so, and it’s right to know it before you sign. Sources change: the ERP/gestionale updates a field, the e-commerce changes an integration, a new channel is born. The business changes: you open a site, you launch a line, you change the way you discount. Every time, if nobody takes care of it, the number starts lying in silence — and that’s worse than a late report, because a late report you know is old, while a wrong number that looks fresh makes you decide badly with confidence.

That’s why a serious data product provides for two things. A declared maintenance (typically 15–25% of the project per year) to keep the connections alive, add a view when a new question appears, fix things when a source changes. And an owner: someone, in the company, whose dashboard it is — who looks at it, notices when a number is strange, and has a channel to get it fixed. A dashboard without an owner dies like a report without an author: slowly, and nobody notices until it’s really needed.

Note well: maintenance doesn’t mean depending forever on a vendor. It means that the code, the definitions and the data are yours, and that there’s a clear agreement on who puts their hands on it when something changes. If tomorrow you want to change horses, you take everything with you.

Signals that you’re buying fluff

Since this is a market full of promises, here are the signals that you’re buying a demo dressed up as a product — the red flags to watch when someone proposes to solve your late report.

The beautiful dashboard built on sample data. If the demo runs on fake numbers, you haven’t seen anything: the real work is on your data, which is dirty. Always ask for a test on a real sample, even a small one.
The ready-made template “we adapt it to you in two days”. A dashboard downloaded from a template is fast to show and useless to use, because it doesn’t know your definitions. If they don’t ask you how you define a sale, run.
Not a word about sources that change. If they don’t explain what happens when the ERP/gestionale updates a field or a source doesn’t respond, they haven’t thought about production: they’ve thought about the demo.
“99% accuracy” without telling you on what. 99% on the headers and 60% on the amounts is a disaster dressed up as a percentage. Get them to explain what that number measures.
The code “stays ours” or only runs on their account. That’s vendor lock-in. The data and the system must stay yours.
The price all at the start, no maintenance. A data product without maintenance is a product that dies in instalments. A serious vendor tells you that; one who gets you to sign and disappears, doesn’t.

If you want to go deeper on this theme — what a serious project actually includes and what is theatre — I cover it at length in the guide to dashboards and data products, which collects all the articles in this thread.

Before you spend: measure your real delay

Before evaluating any project, there’s one thing you can do on your own, this week, for free: measure the real delay. Not the one you imagine — the actual one. For a month, note down three numbers.

The date. On which day the previous month’s report arrives. The exact date, not “around mid-month”.
The hours. How many person-hours it takes to produce it. Ask whoever does it, adding up downloads, reconciliations, layout, corrections.
The missed decisions. The most important number: list the decisions that in the last quarter you would have taken differently if you had known earlier. A customer to call back, a discount to stop, a reorder to bring forward.

Those three numbers — the date, the hours, the lost decisions — are your business case, and they’re worth more than any quote. They tell you if the problem is real and how much it weighs. If the report arrives on the 20th, costs five person-days a month and you missed two important decisions a quarter, you can do the sum yourself. If instead it arrives on the 3rd, costs half a day and you don’t remember a single lost decision, maybe you don’t have this problem — and an honest vendor will tell you so, instead of selling you a dashboard you don’t need.

The exercise also has a valuable side effect: it forces you to define what “late” and “useful” mean for you, which is already half the work. Bring it to whoever you evaluate for the project, me included: that’s where we start.

What changes for whoever does the report today

A legitimate worry, when we talk about automating reporting, is: “and the person who does it?”. It’s worth saying it clearly, because it’s the fear that blocks more projects than it should. Automating the report doesn’t take work away from the capable person: it takes away the stupid work. Today they spend three days laying out and reconciling, and zero minutes asking why the numbers are those. Tomorrow they get the three days back, and they use them for the part that counts: noticing that a customer is slipping, understanding why a line is dropping, preparing the move. The compiler becomes an interpreter.

And it’s also a risk issue for you. As long as the “how the numbers are done” lives in one person’s head, you’re exposed: holiday, illness, resignation, and the report stops. When that knowledge lives in a documented system, the person becomes more valuable (because they finally reason) and you less fragile (because you don’t depend on a single hero with an Excel). Automating is never against capable people: it’s against the work that wastes them.

It’s for you if / it isn’t for you if

It’s for you if: you wait every month for a file to know how it went; the report is done by one person by hand and when they’re on holiday it skips; you’ve noticed more than once a problem when it was too late to fix it; you’re thinking of hiring someone “for the numbers” but you suspect the problem is upstream.

It isn’t for you if: you have a single simple source and the numbers really are enough as they are; you need a one-off report for the bank, not a daily steering tool; your data doesn’t exist yet (if you’ve been selling for three months without an ERP/gestionale, we fix that first); you’re looking for “the AI that decides in your place” — here automation cleans and flags, the decisions stay yours.

Frequently asked questions

Do I have to fire whoever does the report by hand? No. You have to free them from the repetitive work. The person who compiles the file today is often the one who knows the numbers best: freed from the copy-paste chain, they can finally reason on them and watch over the dashboard. Take away the boring work, not the person.

How much does it cost compared with hiring? A pipeline + product project has a one-off cost plus annual maintenance, and starts delivering value in weeks. A junior hire costs 30,000–40,000 € the first year, delivers value after months (if they survive the data cleaning) and starts from zero when they leave. In most SMEs the system is the better deal, and the eventual person makes sense afterwards.

How long until I have the first automatic numbers? A useful dashboard in 6–8 weeks, bedded-in in three–four months. The longest and most valuable phase is agreeing the definitions at the start: that’s where you decide if the numbers will be true.

And if my data is a disaster? That’s the norm, not the exception. Part of the work is writing the rules to clean it. But nobody can invent data that doesn’t exist: if a piece of information isn’t collected anywhere, it has to be collected first.

Is updated every night enough, or do I need real time? To decide, every night is almost always enough. Real time to the second costs a lot more and is for particular cases. Better to invest in right numbers every morning than in instant numbers you don’t trust.

Do the data and the system stay mine? Yes, and they must. Code, pipeline and definitions stay yours: no vendor lock-in. Maintenance is a service agreement, not a leash.

Can we start from a single source and widen later? Yes, and it’s often the right move. You start from the source that weighs most (usually the ERP/gestionale), you bring home a useful dashboard in a few weeks, and you add the other sources in layers. Better a real dashboard on one source than an endless project on six.

Isn’t the accountant (commercialista) enough to have the numbers? The commercialista gives you tax numbers, at month or quarter close: they tell you how it went, for the tax office. A dashboard tells you how it’s going, while you can still act. They’re two different jobs, not in competition: one looks backwards, the other looks at yesterday to decide today.

And if every department wants its own different report? It’s normal, and it isn’t a problem if the definitions are shared. Same base numbers, different views: sales sees pipeline and customers, admin sees cash and overdue, the owner sees the picture. The disaster is when everyone also has different definitions: that’s when the trial-meetings come back on “whose number is the right one”.

What happens if a source breaks overnight? In a system done well, you don’t get a wrong number: you get a warning. The pipeline notices that the ERP/gestionale or the e-commerce hasn’t responded and flags “incomplete data” instead of showing you a distorted total. That’s the difference between a product that knows it doesn’t know and a dashboard that lies with confidence — and with numbers, the second case is much more dangerous than the first.

In one line

If your sales report always arrives late, you’re not missing an extra person or a faster file: you’re missing a product that holds the sources together and gives you yesterday’s numbers on its own, with the alarms when something changes. First the signed definitions, then the pipeline, then the screen — and the capable person who compiles today goes back to doing the only thing that actually counts: deciding on the present.

If you want to understand what it would look like on your numbers, look at the projects I’ve built or drop me a couple of lines: we start from your sources, not from a demo.