Revenue operations is the discipline of running marketing, sales, account management and commissions as one system with one set of numbers. In most companies it stops at the CRM: the pipeline lives in one tool, invoices and payments live in the ledger, and commissions are rebuilt every month in a spreadsheet that nobody fully trusts. When the CRM is connected to the ledger, the question changes from what the sales team believes it sold to what money actually arrived, from which customer, through which channel, and who earned what for it
This guide is written for finance leaders, controllers and operations heads. It explains how revenue operations works when finance is part of the design: how lead source and ownership are recorded, how pipeline stages feed conversion analysis, why revenue and commission must come from confirmed ledger data rather than CRM estimates, and how versioned commission plans, clawbacks and payout approvals keep every figure defensible. It closes with an implementation checklist and the pitfalls that usually derail these projects
What revenue operations means when CRM is connected to the ledger
A CRM is good at recording intent: a lead arrived, a call happened, a deal moved to negotiation, a contract was sent. The ledger records facts about money: an invoice was issued, a payment was received and matched, a refund was posted. The combined system becomes reliable when each part is used for what it does well and the two are joined by stable identifiers, so that a customer, a deal and a payment can be traced to each other without manual lookups
Who owns which number
- The CRM owns lead source, owner, stage, activity history and the expected value of open deals
- The ledger owns invoiced amounts, cash received, refunds, chargebacks and reversals, each recorded as a balanced double entry with a source and a time
- The commission engine owns plan rules, rule versions, calculations and statements, and it reads revenue only from the ledger
- Finance owns approvals, payout postings and the reconciliation between commission expense and the statements people were shown
In Arfinex this split is built into the platform: sales and CRM data sit next to the ledger, treasury and reporting rather than in a separate silo, which is what we mean by a financial and organizational operating system. A CRM finance integration designed this way does not copy totals between tools. It links records and lets each figure keep its origin, so a number on a dashboard can always be opened down to the entries behind it
Lead source, ownership and pipeline stages
Every downstream number, from acquisition cost to commission, depends on two fields captured at the very start: where the lead came from and who owns it. If either can be edited casually, attribution and payouts become arguments rather than calculations
Lead source and ownership
Lead source should be captured from the first recorded event, such as a campaign tag, a referral code or a partner link, and stored with its timestamp. Ownership should be assigned by a rule, for example territory, rotation or a partner agreement, and every reassignment should be logged with who changed it, when and why. A useful convention is that the owner at the moment of the qualifying event is the owner for commission purposes, unless an approved exception says otherwise
Pipeline stages and conversion
Stages need entry and exit criteria that someone outside sales could verify. A typical generic funnel looks like this
- New lead: a contact with a recorded source and consent status
- Qualified: a defined fit check completed and recorded by the owner
- Proposal or contract sent: a document exists and is linked to the deal
- Won: the contract is signed or the order is accepted
- Revenue confirmed: the related payment is received and matched in the ledger
The last stage is the one most pipelines lack. Conversion from won to revenue confirmed exposes deals that were celebrated but never paid, partially paid or refunded, and it is the conversion rate finance should rely on when forecasting cash. With a CRM and customer 360 view connected to ledger events, that stage is moved by the payment itself, not by a salesperson ticking a box
Revenue from confirmed ledger data, not CRM estimates
Deal value in a CRM is an estimate. It may include optional items, assume a full contract term or ignore a discount negotiated at the last minute. Reporting it as revenue overstates performance and, worse, pays commission on money that may never arrive. The rule is simple: revenue used for performance reporting and commission comes from entries confirmed in the ledger, and the CRM value remains a forecast
A generic walk-through
Imagine a deal recorded in the CRM at 12,000 for an annual service. The customer signs, an invoice for 12,000 is issued and the ledger records a receivable. After a negotiated discount and a cancelled optional module, the customer pays 9,000. The payment is matched to the invoice, the remaining 3,000 is cleared with a credit note posted as its own entry, and the confirmed revenue for this deal becomes 9,000. The CRM still shows the original estimate for reference, but every report and every commission calculation reads 9,000, with links to the invoice, the payment and the credit entry
Missing data is never filled with zero. If a payment arrives but is not yet matched to a customer, it is shown as unmatched and excluded from commission until someone resolves it. How revenue is recognized in statutory accounts, for example spread over a service term, is confirmed with your accountant. The operational point is that both views read from the same ledger entries, so they can differ in timing but never in substance
Rules-based, versioned commission plans
Sales commission management fails most often because the plan exists only as a document and a spreadsheet formula. A rules-based plan is defined as data: the base it applies to (confirmed revenue, first payment, or net revenue after refunds), the rate or tiers, eligibility conditions, caps, splits between owners and the period it covers. Commission calculation is then deterministic, testable code that anyone can rerun and get the same result
Why every plan needs versions
Plans change. A new quarter brings new tiers, a partner agreement adds a bonus, a product line gets a different rate. Each change creates a new rule version with an effective date, and every calculation records the version it used. When someone asks why a statement shows a given amount, the answer is the confirmed revenue entries, the rule version and the arithmetic, all reproducible months later
Reversals and clawbacks
When revenue is reversed by a refund, chargeback or credit note, commission must follow. The adjustment is calculated under the rule version that was in force for the original calculation, not under today's plan, so a rate change in the meantime cannot inflate or shrink the clawback. In the example above, had commission been paid on 12,000 by mistake, the 3,000 credit would produce a negative commission line at the original rate, posted as a reversing entry and shown on the next statement with a link to its cause
Approvals for commission payouts
- The engine produces a draft statement per person, with every line traced to ledger entries and a rule version
- The salesperson or partner reviews the statement and raises disputes against specific lines, not against totals
- One person in finance prepares the payout and a different person approves it
- The approved payout is posted to the ledger as commission expense and a liability, then paid
- Any later correction is a new reversing or adjusting entry, never an edit to an approved statement
Our deterministic sales commissions service applies these controls by default. When commissions are paid through payroll, the posting follows the same path described in our guide to HR, payroll and workforce operations connected to finance
Acquisition cost by channel next to revenue
Revenue operations is incomplete if it shows revenue without what it cost to win. When advertising, partner fees and sales effort are tagged by channel and campaign, acquisition cost per channel can sit next to the confirmed revenue of the customers that channel brought in. A channel that produces many leads but little confirmed revenue looks very different from one that produces fewer leads who pay and stay
- Cost per lead and per qualified lead, by channel and campaign
- Customer acquisition cost based on customers with confirmed revenue, not on sign-ups
- Confirmed revenue and refunds per channel over the same period
- Untracked spend flagged for review instead of being quietly spread across channels
The marketing attribution service connects spend to real events and revenue, and a return claim is only recorded when it links to money in the ledger
Customer 360 with financial behaviour
The customer view becomes far more useful when it shows financial behaviour alongside activity: open invoices, payment timing, refunds, disputes and lifetime confirmed revenue. Account managers see which customers are profitable and which need attention, while finance sees which overdue receivables belong to accounts that sales is still actively working. Access to these fields follows roles, so sensitive financial data is visible only to the people who need it
Implementation checklist
- Agree the definitions first: lead, qualified, won, confirmed revenue, refund and the commission base
- Map identifiers so that every CRM customer and deal links to ledger customers, invoices and payments
- Write the current commission plan as explicit rules and record it as the first version with an effective date
- Decide ownership and reassignment rules, and who may approve exceptions
- Build and test in a sandbox with synthetic or anonymized data, including refunds, partial payments and reassignments
- Run in parallel with the current spreadsheet for at least one full commission cycle and explain every difference
- Go live with finance approval, then retire the spreadsheet as a source of truth
Arfinex delivery follows the same sequence: introduction and scope review, corporate identity verification before contract, a sandbox build, a parallel run and go-live with your approval. The labour, tax and accounting treatment of commissions in your jurisdiction is confirmed by your accountant or local adviser
Common pitfalls: spreadsheets, disputes and double counting
- Spreadsheets as the system of record: formulas are copied, overwritten and impossible to audit, and nobody can reproduce last quarter's numbers
- Disputes about totals instead of lines: without line-level traceability every disagreement turns into a negotiation
- Double counting: the same deal credited to two owners, a renewal treated as new business, or a partner and a salesperson both paid in full without a defined split
- Paying on bookings: commission paid before cash arrives turns every refund into a recovery problem
- Silent plan changes: editing a rate in place rewrites history and makes old statements impossible to explain
- Manual revenue stages: a deal marked as paid in the CRM without a matching ledger entry
Each of these has the same cure: one source per number, explicit rule versions, and corrections made as new entries with an approval, never as edits
Revenue operations that finance can sign off
Revenue operations works when the CRM forecasts, the ledger confirms and the commission engine calculates from what the ledger confirms. With source and ownership captured early, a revenue-confirmed pipeline stage, versioned plans, clawbacks under the rule in force and two-person payout approval, sales and finance stop arguing about numbers and start discussing strategy
