Recurring reporting and analysis
The numbers your team rebuilds by hand every month.
The spreadsheet rebuilt from four exports. The deck rebuilt from the spreadsheet. The month-end where two capable people disappear for three days and come back with something that was already out of date. We build it once, with the maths written down, so it runs every period and your team spends those days on what it says.
Month end
Recurring
Month end
Nobody has to start it.
Pull
same mathsEvery source read the same way it was last month.
Check
Numbers that moved more than they should are flagged.
Build
The sheet and the deck, current, in your format.
Your team
Spends the three days on what it says.
The run your team gets after handover.
How month end goes now
- Exports downloaded, opened side by side, pasted across
- Last month’s file copied, renamed, and edited until it looks right
- Two versions in circulation, and an argument about which
- Logic that lives in one person’s formulas and head
- The deck finished the evening before it is presented
How it goes after
- The current version exists without anyone starting it
- The same maths every period, written down where it can be read
- One version, and the source of every figure attached to it
- Anything that moved oddly is flagged before the meeting
- The three days go to the decision, not the assembly
Assembly first, then the analysis your data can actually carry.
Getting the numbers to build themselves is the part that returns the hours, and it is the part we can hold to a written criterion. On top of it, where the history supports it: comparisons that hold their definitions, cohorts, anomaly flags, and forecasts. The team behind Mapular AI has shipped statistical models and monitoring platforms in production, so this is not a stretch for us.
It is a stretch for the data more often than for the method, so the diagnosis says plainly which of these your data can support, including when the answer is that a simple comparison is the honest ceiling. A model your team cannot maintain after we leave is a liability, and we will say so before you pay for one.
Exactly what the build includes
- Every source read the same way each period, so two people cannot get two answers
- The calculations written down and version-controlled, not living in a formula bar
- The sheet and the deck produced in the format your team already uses
- Figures that moved more than they should flagged before anyone presents them
- A record of what changed since last period, and why, where the source can tell us
- Training and handover, so your team changes the logic without calling us
Acceptance criteria, for example
Agreed in writing before the build. The system ships when it meets them; until then, we keep working at no extra cost.
- Hours to close: the month-end measured before and after, same scope
- Agreement: the system's output matches the hand-built version on a past period, line for line
- Freshness: the current version exists by the time it is needed, without anyone starting it
- Change safety: your team can alter a calculation and see what it moves, before it ships
Reads what you already have
Nothing here asks you to move your data somewhere new first.
Sources
- Excel and Google Sheets
- Your ERP or accounting system
- CRM
- Shop and payment platforms
- Databases and warehouses
Outputs
- Excel and Google Sheets
- PowerPoint and Google Slides
- Your existing BI tool
If the source has an API or a scheduled export, we can build on it. Which of them is actually the source of truth is a diagnosis question, and usually a revealing one.
True of every build we do
- Fixed price
- Quoted once after the diagnosis, invoiced once. No day rates and no running meter.
- Criteria in writing
- We agree what the system has to do, and how it will be measured, before anything is built.
- It ships when it passes
- Tested on your data against those criteria. Until it passes, we keep working at no extra cost.
- You own everything
- Code, prompts, data, accounts, documentation. Yours from day one, so there is nothing to be locked into.
- Your team runs it
- Training and a handover built for people who did not write it. If you never speak to us again, it keeps working.
How you buy it
The same three steps for every job we take on. You can stop after either of the first two.
Step 1
Diagnosis
EUR 4,900, two weeks
What this work costs you today, what a system would take off your team, and a fixed quote with the acceptance criteria written down. Credited in full against a build that starts within 90 days. If it finds no job worth building, you get the fee back.
Step 2
Build
from EUR 14,900, fixed after the diagnosis
Built into the tools you already run, so there is no new platform to adopt. Tested against the criteria we wrote down, on your data. It ships when it passes, with training and full ownership.
Step 3
Run
optional
The answer to who owns it after we leave: monitoring, exception handling, and changes as the business changes. You own the system either way and your team is trained to run it, so this is a choice rather than a dependency.
Questions buyers ask
We already have a BI tool. Is this the same thing?
No, and if a dashboard were going to fix this it would have fixed it already. BI tools are good at showing numbers that are already clean and already joined. The work that eats the three days is upstream of that: pulling the exports, reconciling names that do not match, applying last year's adjustments, and rebuilding the deck. That is what this builds. It can feed your BI tool rather than replace it.
Our spreadsheet has fifteen years of logic in it.
That is normal and it is an asset, not an obstacle. The diagnosis reads it, writes down what it actually does, and shows you the parts that no longer agree with each other. Most long-lived spreadsheets contain at least one rule nobody remembers adding, and finding those is often worth the two weeks on its own.
Who is accountable when a number is wrong?
The same person as today: the one who signs the report. What changes is that they can see where every figure came from and what the system did to it, so checking is possible rather than theoretical. Agreement with a hand-built past period is one of the criteria we hold the build to.
Is this forecasting and analysis, or just assembly?
Assembly first, because that is where the hours go and it is the part we can guarantee. Analysis on top of it where the data supports it: comparisons, cohorts, anomaly flags, and forecasts where there is enough history to make one honest. The diagnosis says which of those your data can actually carry, including when the answer is none of them.
Can you do the harder statistical work?
Yes. The team behind Mapular AI has shipped statistical models and monitoring platforms in production, not only reporting. We will still tell you when a simpler method answers the question, because a model nobody in your team can maintain is a liability rather than an asset.
What if our data is a mess?
Then say so on the call, because it changes what the first build should be. Sometimes the honest answer is that the first job is making one source trustworthy rather than automating four untrustworthy ones. That answer costs you a diagnosis, and it is one of the cases where we return the fee.
If the thing that eats the days is a document rather than a spreadsheet, the document someone else is waiting for is the nearer job. They are often bought together.
Bring the spreadsheet.
The real one, with the tabs nobody talks about. Twenty-five minutes with it tells us whether this is worth building and roughly what it would cost.