Metabase and n8n solve two different halves of the same problem: n8n moves and cleans raw billing and CRM data, Metabase turns clean data into a dashboard a RevOps lead can actually trust in front of the board. Bolted together carelessly, the pair just automates a wrong number faster. This guide covers the mechanics that matter: how to define MRR and churn before you build anything, how to structure the n8n pipeline so it does not silently drop or duplicate events, and the specific failure modes that quietly corrupt revenue dashboards once they go live.
Why Spreadsheet Revenue Reporting Breaks at Scale
The usual manual process looks like this: finance exports a CSV from the billing platform, RevOps exports a CRM report, someone merges the two in a spreadsheet and recalculates churn by hand. It works fine at low volume because a human can eyeball the totals and catch anything odd. It stops working the moment two teams start using different definitions of the same word. Finance might calculate churn against the calendar month; RevOps might calculate it against the customer’s billing cycle anniversary. Neither is wrong, but the two numbers will not match, and the first thing that happens in the board meeting is a debate about whose number is correct instead of a decision based on either one.
The second failure is more mechanical: spreadsheet formulas are fragile. A VLOOKUP or INDEX MATCH built against a specific column order breaks silently the moment an export adds or reorders a field, and nobody notices until a number looks implausible weeks later. Reconciliation effort scales with row count, so the manual process gets slower exactly when the business needs it to get faster. Automating the pipeline does not just save time, it removes the point where two people can independently misinterpret what “revenue” means.
Splitting the Work Between n8n and Metabase
The cleanest architecture keeps a strict division of labour. n8n’s job is extraction, cleaning and loading: pulling events from Stripe, Chargebee or a CRM, filtering out noise, deduplicating, normalising currency, and writing a clean, queryable table. Metabase’s job is querying, visualising, filtering and alerting on data that is already correct. See n8n’s documentation for the full node reference and Metabase’s documentation for how questions, dashboards and permissions fit together.
The anti-pattern worth naming explicitly is putting transformation logic inside Metabase native SQL questions that are then copied across several dashboards. The moment someone changes how churn is calculated, that logic now needs editing in five places instead of one, and it is only a matter of time before one of them gets missed. Metabase has a Model feature specifically for this: a Model is a saved, sanctioned query that other questions build on top of, so a definitional change happens once and propagates everywhere. Keep the heavy transformation in the n8n and database layer, and let Metabase Models be the single point where “MRR” is defined for querying purposes.
Defining MRR, Churn and ARR Before You Automate Anything
Automating a bad definition just makes the bad definition update faster. Before touching a workflow builder, write down, in one sentence each, exactly how MRR, churn and ARR are calculated, and get finance and RevOps to agree on the wording. MRR should be the normalised monthly value of every active subscription, derived from the subscription’s current plan and billing interval, not from summing invoice amounts. ARR is not always simply MRR multiplied by twelve: if a meaningful share of revenue comes from annual contracts booked upfront, decide explicitly whether ARR reflects contracted annual value or annualised current run rate, because the two diverge as soon as a customer changes plan mid-term.
Why Gross Churn and Net Revenue Churn Tell Different Stories
Gross revenue churn only counts revenue lost to cancellations and downgrades. Net revenue churn nets that loss against expansion revenue from existing customers, upsells and add-ons, and it can go negative, meaning the existing customer base is growing in revenue even before new logos are counted. A dashboard that only shows one of these two numbers hides where growth is actually coming from. If net revenue churn is healthy but gross churn is rising, the business is retaining revenue through upsells while quietly losing accounts, which is a very different problem to solve than genuinely low churn.
Why Proration Creates False MRR Spikes
When a customer upgrades mid cycle, most billing platforms issue a single prorated invoice that blends the unused portion of the old plan with the new plan’s charge for the remainder of the period. If a workflow naively sums invoice totals and calls that “this month’s MRR”, the proration credit and the new charge both land in the same period and produce a spike that has nothing to do with actual recurring value. The fix is to never derive MRR from invoice totals at all. Instead, build a subscription snapshot: a table that records the plan price and billing interval for every subscription at every point it changed, and calculate MRR from that state, not from what got invoiced. Invoices are useful for cash reconciliation; they are the wrong source for a recurring revenue metric.
Building the n8n Data Pipeline Step by Step
With definitions agreed, the pipeline itself breaks into a small number of concrete stages, each solving one specific problem.
Triggering on Real Events, Not Test Data
A webhook trigger node listens for subscription and invoice events. Immediately after the trigger, add a filter node that checks the event’s live mode flag and drops anything from a test or sandbox environment. Skipping this step is one of the most common reasons a demo or QA session suddenly shows up as a revenue spike on a live dashboard, because test events and production events arrive through the same webhook endpoint unless you explicitly separate them.
Preventing Duplicate Events From Inflating Revenue
Webhook delivery is not guaranteed to happen exactly once. Stripe’s own webhook documentation is explicit that the same event can be delivered more than once and that consumers should handle duplicates. The practical fix is a small dedupe table keyed on the event’s unique ID: before processing an event, check whether that ID has already been recorded, and skip it if so. Without this, a retried webhook can double count a payment or apply the same downgrade twice in the revenue table.
Normalising Currency Without Rewriting History
For any business billing in more than one currency, convert every amount to a single base reporting currency using the exchange rate at the time the invoice or subscription event occurred, not the rate on the day the dashboard is viewed. Store both the raw and normalised amounts. If you instead join against a live FX rate at query time, every historical MRR figure quietly shifts every time the exchange rate moves, which makes month over month trend lines meaningless and makes it impossible to reconcile a number with what was reported last quarter.
The final node upserts the cleaned record into a Postgres staging table, keyed on subscription ID and effective date, using an ON CONFLICT clause so replaying an execution is safe rather than creating duplicate rows.
Modelling Revenue Data So Every Dashboard Agrees
Once the staging table is reliable, connect Metabase and build a single Model on top of it that defines MRR, gross churn and net revenue churn once, rather than repeating the logic inside every dashboard question. Every downstream chart should query that Model rather than the raw table directly. Use Metabase’s caching TTL settings selectively: a heavy cohort retention query can be cached for a few hours without anyone noticing, while a live pipeline health check should stay uncached so a broken workflow is visible immediately rather than masked by a stale cache.
On permissions, give RevOps analysts raw table access for debugging, but restrict the wider organisation to the Models and finished dashboards. This prevents a well-meaning stakeholder from building their own ad hoc join against the raw staging table, arriving at a slightly different churn figure, and starting a fresh reconciliation argument that the whole pipeline was built to eliminate.
Five Failure Modes That Quietly Corrupt Revenue Dashboards
Most revenue dashboard problems are not dramatic outages, they are small silent errors that leave a number wrong without anyone realising for weeks.
Test mode leakage. Without the live mode filter described above, a QA session or sales demo environment can inject events into the production revenue table.
Proration double counting. Deriving MRR from invoice totals instead of subscription state, covered in the proration section above, is the single most common cause of an unexplained mid month spike.
Trial periods inflating early revenue. If a workflow defaults a missing unit price to the previous known value rather than treating it as zero, a customer still in a free trial can appear to be contributing recurring revenue before they have converted.
Retroactive FX drift. Using a live exchange rate at query time instead of the rate at the point the event occurred causes every historical figure to shift whenever currency markets move, which makes trend comparisons unreliable.
Silent workflow failures. If one execution errors on a malformed payload and there is no error handling configured, that day’s records are simply missing. The dashboard does not show an error, it just shows a slightly lower number that looks plausible enough not to question.
Alerting and Governance That Catch Problems Before Leadership Does
Two separate layers of alerting catch different kinds of problem. n8n’s error handling lets a workflow trigger a secondary notification workflow whenever an execution fails, which should post to a Slack or Teams channel the moment a pipeline run breaks, catching failures at the infrastructure level before anyone even looks at a dashboard. Metabase alerts work at the data level: a saved question can be configured to notify a channel when its result crosses a threshold or changes, which catches anomalies that pass through the pipeline successfully but still look wrong, such as churn jumping unexpectedly in a single week.
For governance, export n8n workflows as JSON and keep them in source control alongside a written definition of each metric. When someone asks why net revenue retention looks different this month, a diffable history of both the workflow logic and the metric definition turns a debate into a five minute lookup. Keep a separate staging workflow that runs against test mode webhooks before any schema or transformation change touches the production pipeline, so a broken field mapping is caught before it reaches the live dashboard.
A Four Stage Rollout Order That Avoids Rework
Building everything at once is the most common way this kind of project stalls. A staged rollout keeps each stage small enough to validate against a manual reconciliation before moving on.
Stage one: a single source MRR pipeline from one billing platform only, with no segmentation. The goal is purely to prove the pipeline is accurate and fresh against a manual check for one full month.
Stage two: add gross and net revenue churn cohorts, once the base MRR figure is trusted enough that nobody is still cross checking it by hand.
Stage three: add expansion and contraction revenue, multi currency support, and a second data source such as CRM sourced offline invoices.
Stage four: add pipeline and data level alerting, plus forecast trend lines built on top of the now validated history.
Jumping straight to stage four is the mistake worth naming directly. Building alerts and forecasts on top of unvalidated churn data does not save time, it just automates the propagation of a wrong number faster and with more confidence behind it.
Frequently Asked Questions
Do we need a full data warehouse before connecting Metabase and n8n?
No. A single Postgres database is enough for most SaaS companies at this stage. A dedicated warehouse such as BigQuery or Snowflake only earns its added complexity once query volume or historical data size make Postgres genuinely slow, which for most teams is well after this pipeline is already running.
Why does MRR spike right after a customer upgrades mid cycle?
Because the workflow is summing prorated invoice totals instead of deriving MRR from the subscription’s current plan state. Build a subscription snapshot table and calculate MRR from that, not from invoices.
How do we stop test mode data appearing on production dashboards?
Add a filter node immediately after the webhook trigger that checks the event’s live mode flag and drops anything from a test or sandbox environment before it reaches the staging table.
Should churn and MRR definitions live in n8n or in Metabase?
In n8n and the underlying database. Metabase should only visualise data that is already correctly transformed. Putting transformation logic inside Metabase questions means a definitional change has to be repeated everywhere that logic was copied.
What is the safest first stage to automate if we are starting from scratch?
A single source MRR pipeline from one billing platform, with no segmentation, validated against a manual reconciliation for a full month before adding churn cohorts, multi currency support or alerting.
For more on this, see more on reporting and data, including Automate Sales Ops Reporting with n8n and Google Sheets, How to Automate RevOps Analytics with n8n and Metabase Dashboards, and Automating RevOps Reporting with Tableau and n8n Workflows.
Leave a Reply