Revenue data architecture: the 30-day design

Revenue data architecture is the design that states which system holds each entity of the commercial operation, such as account, contact, deal, order, contract and ticket, which key identifies the same customer across every system, where each piece of data travels and how often. Without that design, each team answers for its own version of the truth, and the board spends the meeting arguing about which number is right. The cost reaches the bottom line: in Forrester’s 2023 Data Culture And Literacy Survey, more than one quarter of data and analytics employees who see poor data quality as an obstacle estimated losses above 5 million dollars a year, and 7% reported 25 million or more (Forrester, 2024). Designing the architecture does not require buying a system. It requires the board to decide, entity by entity, who the owner is, and to hold that decision on the day one team wants to edit what belongs to another.

In a hypothetical example, the sales director presents R$ 2.4 million in new revenue for the quarter, the sum of the deals marked as won in the CRM. Finance shows R$ 1.9 million in the ERP, because R$ 300 thousand were signed in the last week and have not been invoiced yet, and another R$ 200 thousand have their first installment scheduled for the next quarter. The customer success spreadsheet shows R$ 2.2 million, because it excludes two contracts of R$ 100 thousand that customers cancelled during onboarding and that the CRM still shows as won. All three numbers are correct by each team’s rule, and the meeting spends forty minutes reconciling. Gartner names inconsistency across sources, the result of data stored in silos with overlaps and gaps, as the most challenging data quality problem (Gartner, 2024).

What is revenue data architecture?

Revenue data architecture is the set of decisions that organizes marketing, sales, finance and customer success information around the same entities. An entity, in this context, is each type of thing the operation records and counts: the customer company, the person you talk to, the opportunity under negotiation, the invoiced order, the signed contract and the open support case. The design has five parts: the owning system for each entity, the systems that read it, the key that links the records, the sync frequency and the layer where the board consumes the numbers.

Choosing the tools belongs in a different document: in sales stack I cover the layers, the data each tool returns to the CRM and the criteria for cutting licenses. The architecture applies to any combination of tools and answers a different question: when the same customer shows up in six systems, which record counts, how you know it is the same customer and how long a change takes to reach the others.

Which systems belong in the data architecture?

Every place where someone records information that later becomes a board number belongs in it. The CRM holds the commercial relationship, marketing automation holds lead source and consent, and the ERP holds tax registration, orders, invoices and payments. The service tool holds support cases, and the product system, when the company sells software or a service with measured usage, holds who uses it and how much.

Two pieces usually stay off the map, and they distort the results the most. The first is spreadsheets: the customer success portfolio and the commission tracker work as systems, with an owner and rules of their own, and the architecture decides whether each one becomes an official source, moves into a system or goes out of circulation. The second is BI, the analytics layer that combines the systems and publishes the dashboards. BI only reads and owns no entity, and a correction made directly in the dashboard disappears with the next load.

What is the source of truth for each entity?

The source of truth, or system of record, is the system where the entity is created, where official changes happen and whose version prevails when two systems disagree. The rule that holds the design together is one owner per entity, or per group of attributes within it. The other systems read and can display the information, without editing it. The table below is the instrument I bring to the first meeting with the board, and the leaders fill it in with their own company’s systems.

Entity	What it represents	Owning system	Systems that read it	Key	Frequency
Account	The customer or prospect company	CRM for commercial data; ERP for legal name, CNPJ and tax address	Automation, service, product and BI	Customer master ID, with CNPJ	On creation and daily
Contact	The person at the customer company	CRM; automation for consent	Automation, service and conversation tools	Corporate email	Continuous
Deal	The opportunity under negotiation	CRM	BI and proposals	Deal ID in the CRM	Continuous
Order	What was sold and will be invoiced	ERP	CRM and BI	Order number, with the originating deal ID	On win and daily
Contract	Term, value, price adjustment and conditions	Signature tool or legal, with a copy in the ERP	CRM, ERP, service and BI	Contract number, with customer master ID	On signature
Ticket	The case opened by the customer	Service tool	CRM and BI	Ticket ID, with customer master ID	Daily
Product usage	What the customer does in the product or service	Product system	CRM, service and BI	Customer master ID	Daily
Invoice and payment	Invoice issued, due date and settlement	ERP	CRM, service and BI	Invoice number, with order number	Daily

Each row takes minutes to fill in and sometimes a week to approve, because it settles a dispute between teams. Start with the entities that appear in the board’s numbers.

When an entity has two owners

The account is the classic case of split ownership. The ERP owns the tax attributes, because the invoice goes out with the legal name and the CNPJ (the Brazilian company tax ID) that finance validated, and the CRM owns the commercial attributes, such as segment, size, account owner and customer stage. The split works when it is written attribute by attribute and the integration respects the direction: the salesperson finds the legal name locked in the CRM and asks finance for the correction. Without that lock, the next load brings back the old value, and the team concludes the system does not work.

Orders and contracts count different revenue

The contract states how much the customer committed to pay and for how long, and it feeds contracted revenue and renewals. The order states what will be invoiced and when, and it feeds invoiced revenue and cash. The board needs both numbers under different names, and the architecture links each order to its contract and originating deal, so you can explain the difference without building a spreadsheet. The path from the won deal to the first payment is covered in lead to cash.

How do you define the unique customer key?

The unique customer key is the identifier that lets you state that the CRM record, the ERP registration, the account in the service tool and the product user are the same company. Without it, BI matches the systems by name, and “Grupo Alfa Ltda.”, “Alfa” and “ALFA INDUSTRIA” become three customers. In Brazilian B2B, the CNPJ is the natural starting point, and on its own it does not solve the problem.

The first eight characters of the CNPJ identify the company, the next four identify the establishment and the last two are check digits. A customer with a headquarters and four branches has five CNPJs, and the board needs to decide whether it counts one customer or five. Business groups make it harder, because companies with different roots can answer to the same buyer. I recommend creating a customer master ID, generated by a single system, usually the CRM or the ERP, and a cross-reference table that stores, for each master ID, the identifiers of the same customer in every system. The CNPJ comes in as a validated attribute, the root groups the establishments and a business group field links the companies that buy together.

The field format also needs a review now. Since July 2026, Brazil’s Federal Revenue Service has been assigning alphanumeric CNPJs to new registrations, and existing numbers remain valid without change (Receita Federal, 2024). A CNPJ field set to accept only digits, or an integration that treats the CNPJ as a number, rejects customers registered after that date. For contacts, the key is the corporate email, and the registration and deduplication rules that keep these keys clean are in CRM data quality.

How often should each system sync?

The right frequency depends on how long the decision supported by that data can wait. Real time costs more, breaks more easily and only pays off when someone acts on the data within minutes.

Pattern	How it works	When to use it	Example in the operation
Event-based	The owning system sends the change the moment it happens	The next person needs to act within minutes	A new lead entering the SDR queue; a won deal creating the order in the ERP
Hourly	A routine pulls the changes from the last hour	The information guides the day’s work	A critical case that appears on the account record for the salesperson
Daily	A nightly load moves the whole day at once	The decision happens in the weekly or monthly meeting	Payments, delinquency and product usage for BI and the CRM
Closing snapshot	BI freezes the numbers at an agreed time	The official number for the period has to be the same for everyone	Monthly revenue frozen on the first business day at 10 a.m.

The last row fixes a divergence few people notice: if sales pulls the report at 9 a.m. and finance at 3 p.m., the two numbers differ by whatever came in between. The snapshot published in BI, with a written time, gives the board one official number per period.

What happens when there is no data architecture?

The divergence in the board meeting has three causes, and each one calls for a different fix. The first is definition: “active customer” means a contract in force for customer success, an invoice paid in the last ninety days for finance and a won deal for sales. The second is the key, which makes the same customer appear twice in one base and not at all in the other. The third is timing, with systems synced at different times or not synced at all. The architecture tackles the last two, and the definition of each metric goes in the metrics matrix, as I describe in RevOps metrics.

The most expensive effect shows up in decisions. The board postpones hiring because it does not trust the forecast, and marketing loses budget because it cannot prove revenue by source. When the number on the screen differs from the spreadsheet prepared the day before, leadership goes back to the spreadsheet, and the sales dashboard becomes decoration.

Artificial intelligence raises the price of having no design. The agent that summarizes the account before a call reads the CRM, the ERP and the service tool, and if the key does not link the three, it summarizes half of the customer with full confidence. In a survey of 1,203 data management leaders conducted in July 2024, 63% of organizations said they either do not have or are unsure if they have the right data management practices for AI, and Gartner predicts that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data (Gartner, 2025).

Who owns the revenue data architecture?

The architecture needs a sponsor on the board, because each row of the map takes editing power away from someone, and only the board can arbitrate that dispute. Each entity has a business owner, the team running the process where the data is created, and revenue operations maintains the map while IT implements integrations and BI. In the diagnostics I run, the architecture that lasts is the one with each owner’s name written on the map itself, along with the date of the last review.

Role	Who it usually is	Answers for	Approves
Sponsor	Chief revenue officer, CEO or CFO	Arbitrating conflicts between teams and holding the map accountable in the board meeting	The entity map and the official definitions
Entity owner	Leader of the team where the data is created: sales for deals, finance for orders and invoices, customer success for tickets	Registration rules, required attributes and corrections for the entity	Changes to the entity’s own attributes
Operations architect	Revenue operations	Designing and maintaining the map, the cross-reference table and the frequency of each flow	New integrations and new fields that cross systems
Technical implementation	IT or data team	Integrations, security, access and BI loads	Vendors and the technical form of each flow
Database steward	CRM administrator or operations analyst	Deduplication, cross-reference table and integration errors	Imports and merges
Users	Salespeople, analysts, support agents and finance	Recording in the owning system and asking the entity owner for corrections	Nothing; they flag problems

In smaller companies, one operations person combines the architect and steward roles, and IT can be an outside vendor, but the sponsor remains indispensable. The structure of the team that sustains this work is in RevOps team.

Common mistakes when designing the data architecture

Starting with BI

The company buys a BI tool expecting it to reconcile the numbers. If the systems share neither key nor definition, the new dashboard shows the same divergence with better charts, so the map and the key come before any dashboard.

Two systems editing the same entity

Two-way integration looks like the most complete option and creates a permanent dispute: a correction made in the CRM goes back to the old value when the ERP syncs. Each attribute needs a single system that edits it, with the others only reading.

Using the company name as the key

Names change with mergers, with new trade names and with the way each person types. Matching by name loses customers and creates duplicates that the database steward takes weeks to fix.

Syncing everything in real time

Real time in every flow multiplies cost and failures, and most board decisions happen in weekly or monthly meetings. Keep event-based sync for whoever acts within minutes and use a daily load for the rest.

Designing without finance

Projects led only by marketing and sales stop at orders and contracts, which belong to another executive. Finance joins from the first meeting, because it owns the entities that close the revenue numbers, and its spreadsheets go on the map as systems.

How do you prepare the team to sustain the architecture?

The map becomes routine when each person knows which system they record in and whom to ask for a correction. Leaders learn to read the map and to demand the official number in the meeting, turning down the parallel spreadsheet. The database steward and the operations person learn to maintain the cross-reference table and review integration errors. Salespeople, analysts and support agents need a short session, in the company’s own system, on the locked fields and the correction path. In the operations I support, the strongest resistance comes from people who lost permission to edit a field, and an explanation of the reason, given by the entity owner, works better than any technical lock.

30-day roadmap for leadership

In four weeks leadership designs and decides, and the implementation of the integrations moves to the following quarter, with the map approved.

1. Days 1 to 3: name the sponsor and the person leading the design. The board tells the teams that the map will carry the weight of a rule.
2. Days 4 to 7: run the board number test. Classify each difference between teams by definition, key or timing.
3. Days 8 to 12: list systems and spreadsheets. Include every spreadsheet that feeds a leadership meeting, with its owner.
4. Days 13 to 17: fill in the entity map. Define owning system, readers, key and frequency, with each team’s owner in the room.
5. Days 18 to 20: decide the unique customer key. Choose who generates the master ID, the rule for headquarters, branches and groups, and the CNPJ format.
6. Days 21 to 24: set the frequencies and the closing snapshot time. Write down the official time for each board number.
7. Days 25 to 27: name the owners and approve the map. The sponsor arbitrates the disputed rows.
8. Days 28 to 30: plan implementation and training. Rank the integrations by their impact on board numbers and schedule the sessions for each profile.

If your board spends the meeting reconciling numbers instead of deciding, that is the work of the in-company Revenue Operations training. I run the program with the marketing, sales, customer success, finance and IT leaders in the same room, working on the systems and numbers of your operation. The group leaves with the SLA between marketing, sales and CS, which defines what each team delivers to the next, and with the RevOps metrics matrix, which records each metric’s definition and the system it comes from, the basis for the entity map.

Frequently asked questions

What is revenue data architecture?

It is the design that defines which system holds each entity of the commercial operation, such as account, contact, deal, order, contract and ticket, which systems read each one, which key identifies the same customer across all of them and how often the data syncs. With it, the board works with one official number per metric.

Should the CRM be the source of truth for everything?

The CRM is the source of truth for the commercial relationship, with contacts, deals, activities and account ownership. Orders, invoices and payments belong to the ERP, and support cases belong to the service tool. The CRM displays this data on the customer record without editing it.

What is the best unique key for B2B customers in Brazil?

A master ID generated by a single system, with the CNPJ as a validated attribute and a cross-reference table holding the customer’s identifiers in each system. The CNPJ root groups headquarters and branches, and a business group field links different companies that buy together. The CNPJ field needs to accept letters now that the alphanumeric format has arrived.

Do I need a data warehouse to have a data architecture?

The architecture comes before the tool and works with the systems the company already has. A data warehouse, a database that gathers data from several systems for analysis, helps when the volume and the number of sources grow, and it inherits the key and definition problems if the map does not exist.

Who should approve the entity map?

The sponsor on the board approves the map and arbitrates the disputed rows, and each entity owner approves the rules for their entity. Revenue operations leads the design and keeps the document up to date, and IT validates the technical feasibility of each flow.

How do you prepare the team to work with the new architecture?

Start with the leaders, who need to read the map and demand the official number in the meeting. Then train the database steward and the operations person to maintain the key and the integrations, and run short sessions with each user profile on where to record and whom to ask for corrections. Measure by the parallel spreadsheets that stop circulating and by the time spent reconciling in the board meeting.