A Dublin software company reported monthly recurring revenue from its billing system, its CRM and its warehouse. The three never matched. The gap was about 4%, and it moved every month.
Before each board meeting, the finance team spent two days deciding which number to defend.
- Trace single eurosEngineers followed individual subscriptions through all three systems until every difference had a name.
- Name the causesThree did most of the damage: one system cut months at midnight UTC and another at midnight in Dublin, refunds were counted as paid, and annual plans were spread two different ways.
- Write the rules as testsEach rule became a model with a test the finance team can read, so a change that moves the number fails before it reaches a report.
- Finance signs the definitionThe CFO approved one written definition of recurring revenue, and every dashboard now computes it the same way.
SELECT date_trunc('month', paid_at) AS month, sum(amount_eur) AS mrrFROM billing_invoice_linesWHERE status IN ('paid', 'refunded')GROUP BY 1;- AI tracepaid_at is stored in UTC. In summer, payments made in the first hour of a month in Dublin land in the previous month.
- EngineerConverted to Europe/Dublin before truncating, and netted refunds instead of counting them. Both fixes have tests.
- Your CFOApproved the written definition of recurring revenue that this model implements.