Your commerce hub is your single source of revenue truth, treat it that way

Your commerce hub knows what each customer bought, what they pay, when they renew and what they owe right now. That makes it the natural home for the money facts of your business. Other systems, such as your CRM, analytics and finance sheet, should read those facts from it and never invent their own versions.

This applies whichever hub you use. HubSpot has its own commerce tools, and Stripe is a common billing platform. The principle is the same.

Open a document and write down every money fact someone in your business uses. A typical list:

1. Customer billing identity: legal name, billing email, tax details.
2. Subscription status: active, paused, cancelled.
3. Plan or product, and the amount.
4. Renewal date and billing frequency.
5. Payment status and failed payments.
6. Invoices and credit notes.
7. Totals built from the above: MRR, active customers and churn.

Add any others you use, such as discounts or contract length.

Next to each fact, write the one system that owns it. Use a short rule:

• The commerce hub owns billing identity, subscription status, plan, amount, renewal date, payment status and invoices.
• The CRM owns the relationship: contact owner, pipeline stage, notes and communication.
• The finance sheet owns nothing new. It reads totals from the hub.

Only one system may say "this customer is active and pays this amount". The others display it, read-only. If two systems can both edit a field, you will get a flapping value that overwrites itself. Wire the commerce hub to the CRM explains how to set up the direction of flow and the shared identifier.

Search for every spot where someone types a money fact by hand: a "status" dropdown in the CRM, a column in the finance sheet, a Slack message saying a customer upgraded. For each one, either make it read-only, replace it with a field synced from the hub or delete it. Hand copies are where disagreements start.

Write one definition each for MRR, active customers and churn, and say where each is calculated. For example: MRR is the sum of the monthly value of all active subscriptions in the hub, with annual plans divided by twelve. Churn is customers whose subscription ended in the period divided by customers active at the start. Put these in a document everyone can find. When two people quote different numbers, the definition settles it.

On the first working day of the month, pick ten customers at random. For each, compare status, plan and amount across the hub, the CRM and the finance sheet. Any mismatch is a bug in the rule, not a mistake by whoever noticed it. Find which system was edited by hand, fix the cause and note it. Ten customers takes 20 minutes and catches problems while they are small.

Record the ownership table, the identifier and the definitions in one place with the date and the reason. When someone later wants to add a second system or a new sync, they read it first. Decisions you cannot find are decisions you will make again.

• Setting up products and prices first, and deciding ownership later. Retrofitting ownership across hundreds of customers is slow.
• Letting sales edit subscription fields in the CRM "just to fix it". Fix it in the hub and let it sync.
• Matching customers on email instead of a stable identifier.
• Calculating MRR in a spreadsheet from a manual export that nobody updates.
• Giving everyone admin rights to the hub. Limit who can change prices and subscriptions.

Your monthly check finds no mismatches, or only ones you can explain. Anyone in the company can say where to look for a customer's status and be right. MRR in the dashboard, the finance sheet and the board update are the same number. And when a customer shows as cancelled in one place, it shows as cancelled everywhere within minutes.