Almost every mid-market company that has grown past a certain point ends up running a customer relationship system and an enterprise resource planning system alongside each other, and almost all of them end up with the same argument. Sales says the pipeline number is right. Finance says the revenue number is right. Both are correct, because they are measuring different things and nobody ever wrote down which system owns what. That unwritten boundary is the most expensive piece of undocumented architecture in a growing business.
Duplicate data is not an integration problem. It is a consequence of two systems both believing they own the customer, and no integration will fix a question of ownership
Getting this right is a design exercise that takes a fortnight and saves several years of reconciliation.
Name the owner for each object, once
For every shared entity there must be exactly one system of record, one place it is created, and a direction of flow that never reverses. Account and company. Usually created in the customer system for prospects, but the billing entity — legal name, tax registration, payment terms, credit limit — must be owned by the finance system, because that is where the consequences land. These are two different objects that everyone insists on calling the customer. Contact. Customer system, uncontested. Product and price. Finance system owns the catalogue and the list price. The customer system consumes it. Sales-negotiated discounts are an attribute of the quote, not a change to the price book. Quote and order. Quote belongs to the customer system. The order is the handover, and it should be a single, unambiguous, one-directional event. Invoice, payment, credit note. Finance system, always, with read-only visibility pushed back so sales can see whether a customer has paid. The common failure is letting both systems create accounts. Once that is permitted, duplicate customers appear within weeks and no matching logic will ever fully clear them.
| Record or event | Proposed responsibility | Boundary to document |
|---|---|---|
| Prospect and contact | Customer system | Separate the sales account from the billing entity. |
| Billing entity and credit terms | Finance system | Publish controlled read-only visibility to sales. |
| Catalogue and list price | Finance system | Keep quote-specific discounts separate. |
| Quote to order | Sales handover to finance | Define trigger, validation, failure owner and later changes. |
| Invoice, payment and credit note | Finance system | Expose status and explain reconciliation differences. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The handover is the whole design
Most integration pain concentrates at one point: the moment a quote becomes an order. Get four things settled and the rest is plumbing. What triggers it — a signature, a stage change, an approval — and is it a single definable event? What must be complete before it fires, validated at source rather than rejected downstream? What happens when it fails, and who is told, by name, rather than a log nobody reads? And what happens when an order changes after the fact, which is the case every implementation postpones and every business encounters in month two.
Reconciliation is a design output, not a monthly chore
Decide in advance which numbers should agree between the two systems and which should not. Bookings and revenue should not agree; that is the point of revenue recognition. Order value and invoiced value should agree, eventually, with a defined explanation for the gap. Build the small report that shows the difference and its reason, and run it weekly. The organisations that do this stop having the argument. The ones that do not have it every month at the close meeting, with increasingly senior people in the room.
Practical Guidance for Revenue Architecture Design
- Write one ownership table covering every shared object.
- Separate the sales account from the billing entity — they are different.
- Permit account creation in one system only.
- Keep the price book in finance and discounts on the quote.
- Define the quote-to-order event as a single trigger with validation.
- Name a human owner for integration failures.
- Design the change-after-order path before go-live.
- Build the reconciliation report as part of the project, not after.
The Regional Angle
The first structural complication here is the legal entity. Regional groups commonly sell the same product through several entities — a mainland company, a free zone company, an offshore vehicle, and operating companies in other Gulf states — chosen per deal on the basis of tax treatment, customer location, licence scope, or which entity holds the relevant registration. Sales systems generally model one account per customer; finance systems model the transacting entity, which may differ per order for the same customer. If the boundary does not accommodate that, salespeople start creating an account per entity and the customer view fragments permanently. Model the customer once, model the contracting entity as a property of the opportunity, and decide the entity before the quote rather than at invoicing. The second is that e-invoicing has quietly made the handover a compliance event rather than an internal one. Under the Saudi regime an invoice is cleared or reported through the tax authority's platform in a defined format with mandatory fields, and similar mandates are advancing elsewhere in the region. That means the finance system's invoice is no longer a document you can amend informally when sales realises the purchase order number was wrong, and it means fields that used to be optional — the buyer's tax registration, the precise item description, the correct entity details — must be captured accurately upstream, where the salesperson is. Push the mandatory-field validation back into the quote. The alternative is a rejected submission and a credit note process that nobody enjoys. The third is about the sales practices these systems have to represent honestly. A great deal of regional business is transacted through distributors, agents and channel partners, with commission structures, exclusive territories and back-to-back arrangements that the standard object model does not contemplate. The end customer, the invoiced party and the party who negotiated the deal are frequently three different organisations, and each needs to be visible for a different reason — pipeline credit, revenue recognition, and commission calculation respectively. Decide explicitly which of the three your account object represents and carry the other two as related records. Organisations that leave this ambiguous end up calculating commission in a spreadsheet, permanently.
The objection worth taking seriously
The strongest objection is that this is over-engineering for a mid-market company. A fortnight of design, an ownership table and a weekly reconciliation report is the kind of architecture a business with a data governance function builds, and the company in question has forty salespeople and one financial controller. In practice the controller knows where the discrepancies are, fixes them in an hour a month, and would rather have that hour than sit in a design workshop. Formalising it adds process to a problem that a competent person is already absorbing. That is true while the person is there, and it is a reasonable position for a company that is not growing. The difficulty is what happens at the two moments when it stops being true. The first is scale: the hour a month becomes a day a week somewhere around the point where order volume doubles, and by then the duplicate accounts have been accumulating for two years and cleaning them is a project rather than a task. The second is departure. The knowledge of which number is right and why lives entirely in one head, and when that head leaves the organisation discovers it cannot reconcile its own revenue. The ownership table is not primarily a control document; it is the written form of what your controller already knows. Writing it down costs a fortnight now and is close to impossible to reconstruct later.
Common Questions
Should the integration be two-way?
For most objects, no. One-way flow with read-only visibility in the other direction prevents the majority of conflicts, and bidirectional sync should be reserved for the few fields that genuinely need it.
Which system should hold the credit limit?
Finance, because it bears the consequence. Surface it in the sales system as read-only so nobody promises terms that will be refused.
How do we handle an order that changes after invoicing?
With a defined credit-and-reissue path that both systems understand, designed before go-live. Improvised amendments are where audit trails break and, under e-invoicing mandates, where compliance breaks too.
What should we expect over the next twelve months?
Expect assistant features in both systems to make the duplicate-record problem more visible, because a model answering questions across both will surface inconsistencies people had learned to ignore. Expect e-invoicing mandates to keep expanding across the region and to keep pushing validation upstream into sales. And expect the ownership question to become harder as agentic features start creating records automatically in both systems.
Revenue Architecture Design — we settle who owns what before the integration is built, which is the only time it is cheap.