When Your AI Disagrees with Your Finance Team

Your marketing team reports one number for active customers. Finance reports a different one. Product reports a third. You schedule a meeting to figure out who's right, and the meeting ends with everyone defending their dashboard. Nothing gets resolved because the disagreement isn't about data quality — it's about what the word "active" means to each team.

This is not a reporting problem. It becomes a training data problem the moment you connect any of those dashboards to an AI forecasting or churn prediction tool.

Four teams, four definitions, one broken model

Marketing ties "active" to attributed conversion events — a customer is active when they complete a checkout or start a trial. Finance ties it to recognized revenue: an account with a paid annual contract but no recent invoice might not appear in their count at all. Product teams, following GrowPanel's documentation on active user measurement, define activity as a meaningful in-product action — not access, not payment, but something like running a build, scheduling a report, or logging a CRM entry. Billing systems, meanwhile, count any account with valid access entitlements as active regardless of whether anyone logs in.

These are not variations on the same idea. A customer with a paid annual contract and zero logins in 90 days is simultaneously active under the billing definition and inactive under the product usage definition. No adjustment to invoice timing or attribution windows closes that. The divergence is structural.

When fixing the attribution window doesn't fix the forecast

The strongest argument against spending time on definition alignment is this: most count mismatches between marketing and finance trace to timing mechanics, not semantics. Marketing attributes a customer at checkout. Finance recognizes the same customer after the invoice clears, sometimes 30 days later, after any refund window has passed. Align the attribution windows, exclude refunded transactions, and the numbers converge. No glossary required.

This argument is credible for reporting disputes. It breaks down when you ask what happens to the AI model trained on two years of customer data labeled by different teams.

Actian's data governance guidance makes the mechanism explicit: without a governed definition linked to specific fields and tables, each tool writes its own view of "activity" into whatever dataset it touches. That inconsistency doesn't stay in the dashboard. It gets written into training labels. A churn prediction model trained on marketing-labeled data learns one pattern of "activity." The same model trained on finance-labeled data learns a different one. Both models run on the same underlying customer records and produce conflicting forecasts — not because the models are wrong, but because they were taught different things about what "active" means. Attribution lag is a recoverable error once you fix the pipeline. Label corruption in training data compounds with every model run.

What a governed definition actually looks like

Actian's example of a business glossary entry is worth taking literally: "Active Customer: a customer who has made a purchase in the last 90 days," linked directly to the fields and tables where that rule is implemented. The definition only becomes consistent when it exists at the data layer, not in a slide deck or a team wiki.

Gartner's data governance framing adds one useful nuance: a shared glossary doesn't require every team to use the same definition for every purpose. It requires that each definition be named, documented, and connected to specific data fields so that when a model ingests a label, you know which definition produced it. Marketing's "active" and finance's "active" are allowed to differ. They are not allowed to both be called "active" in the same training dataset without a flag distinguishing them.

RFM analysis — scoring customers on recency of purchase, frequency of transactions, and monetary value — gives founders a behavioral vocabulary that travels across teams. Recency is a number. Frequency is a number. Both translate into explicit, auditable rules that any system can implement the same way.

The practical starting point is narrow: pick one definition, write it down with the specific field names and the time window, and make sure every system that labels customer data uses it. Your AI tools will produce inconsistent outputs until you do. Not because the tools are flawed, but because you gave them inconsistent instructions written in the same word.