The Distributor RevOps Playbook

Why "billing" is the wrong word

The recurring-billing category treats vendors-selling-direct as the canonical case. A SaaS company with a catalogue, a checkout, a set of subscriptions, and one invoice per customer. That isn't what Australian cloud and software distributors do.

A distributor sits in the middle of a two-sided, many-to-many channel graph. On one side, a dozen vendors — Microsoft, Dropsuite, Datto, Sophos, N-able, AWS, and eight others — each with their own invoice format, cadence, usage feed, and occasionally their own PDF-only export of last resort. On the other side, hundreds of MSP partners, each with their own pricing agreement, their own end-customers, their own tenant identities, and their own opinions about when a credit should be applied.

The work that makes all of that go isn't billing. It's reconciliation, pricing rule governance, tenant identity resolution, and evidence trail maintenance. Billing is the output. The category is distributor revenue operations.

Pattern 01 — Treat the vendor feed as input, not truth

The single most expensive mistake we see is distributors who ingest a vendor's invoice or usage feed and generate partner invoices directly from it. The vendor feed is not the source of truth. The vendor feed is one of three inputs in a three-way match.

The three inputs are (1) the vendor invoice, (2) the vendor usage feed, and (3) your priced partner ledger. Every partner-facing line should be the result of all three agreeing — on quantity, on rate, on tenant, on period — before it leaves the building. When they disagree, that's not a problem to hide; that's exactly the signal you need.

"In our first reconciliation run we found seven lines of drift on a single vendor we'd been re-keying for two years. The engine paid for itself in one period."

Pattern 02 — Version pricing rules in time

Partner pricing is not a single markup. It is tiered, per-SKU, with volume breaks, commitment floors, anniversary discounts and the occasional carve-out negotiated directly by a sales lead whose email thread no-one has found since.

If those rules live as the current state of a spreadsheet, every back-dated change is silent. Every auditor question takes ten minutes. Every partner dispute relies on operator memory.

Version the rules in time. Every priced line should store the exact rule id, with version, that priced it. When a partner asks "why did you charge me this rate?", the answer is one click away, not a ten-minute hunt.

Pattern 03 — Canonicalise tenant identity

The partner graph is not stable. Partners merge, acquire, rebrand, split into subsidiaries, consolidate into holding companies. The vendors you ingest from do not coordinate. Microsoft has one view of a tenant's name; Dropsuite has another; the partner's own PSA has a third; your CRM has a fourth.

Maintain a canonical tenant graph with explicit identity edges between vendor tenant ids, partner entities, and end-customers. Do it on day one, not when you've invoiced the same partner twice under two different spellings.

Pattern 04 — Make FX deterministic

Vendors bill USD. You report in AUD. Your NZ entity reports in NZD. Margin calculations that use "whatever the spot rate is when we run the report" will drift between the reconciliation view and the GL by the quarter. Lock the FX rate per line, at reconciliation time, and store it. The report is deterministic. The GL is deterministic. The margin number is the margin number.

Pattern 05 — Run a shadow period before you switch

Never cut over a reconciliation platform cold. Run a parallel, shadow close for one or two periods against your existing stack. Compare line by line. The shadow run almost always surfaces drift — usually in your favour, because the new engine catches what the old process missed — and it lets the operations team trust the output before their livelihood depends on it.

Pattern 06 — Put exceptions in front of the operator, not a log

Exceptions that live in a log file are exceptions that never get resolved. Every mismatch should be a first-class object: categorised, owned, due-dated, evidenced. The ops console shows a queue, not a spreadsheet.

Pattern 07 — Sign-off is a first-class event

No partner invoice should ever generate from an unsigned-off period. Sign-off is evidenced — who, when, with which exceptions outstanding, with what override reasoning — and the signed ledger is immutable. This is also how you answer the auditor without calling a meeting.

Pattern 08 — Retroactive credits need backward pointers

A vendor issues a credit six weeks after the period closed. The credit relates to specific lines inside that period. Without a retroactive linkage model, that credit either hits the distributor P&L (and never reaches the partner) or gets manually chased, badly. The ledger needs to reopen the affected period, map the credit to affected lines, and route the recovery task to ops.

Pattern 09 — Make the partner portal do real work

A portal that only shows invoices is a portal nobody opens. Make it the front door: invoice download, dispute submission, vendor ticket routing, licence provisioning, catalogue browsing. Every interaction in the portal is a ticket your ops team didn't have to handle.

Pattern 10 — Keep the data Australian

Your government-adjacent partners will ask. Your IRAP-aligned partners will insist. Even your commercial partners will ask more loudly in 2026 than they did in 2022. AU-primary data residency is no longer a nice-to-have for distributor billing stacks.

Pattern 11 — Measure margin daily, not quarterly

Margin leakage compounds silently. The difference between seeing a drift the day it starts and seeing it in the quarterly review is usually six-figure. A live margin surface, with alerting on floor breaches per SKU and per partner, is the single largest financial return this category delivers.

Pattern 12 — Connect the journal, then stop

Post the billed ledger directly to your GL with line-level lineage preserved. Do not re-key. Do not reconcile twice. The reconciled ledger is the GL journal. This is the bar.

Anti-patterns

• "We'll just use the CSP portal." The CSP portal is a vendor tool. It will never reconcile your other eleven vendors.
• "We bought a billing platform and we'll customise it." The platform wasn't designed for your shape. Customisation is a permanent project.
• "Our spreadsheet works fine." It works until the operator takes leave.
• "We'll sort reconciliation next quarter." Next quarter's drift has already started.
• "Multi-year contracts keep pricing stable." Multi-year contracts keep the vendor's pricing stable.
• "We don't need AU-hosted." Your next tier-one partner will.

Worked example

A Sydney-based cloud distributor, 140 MSP partners, 9 vendor feeds including Microsoft CSP, Dropsuite, Datto, Sophos and AWS Marketplace. Before: 9-day month-end close, margin reviewed quarterly, 22 "where's my invoice" tickets per month, annual audit took a month. After: 3-day close, daily margin dashboard, 4 tickets per month, audit cleared in two weeks. First reconciled period surfaced $18,400 in vendor drift that had been silently leaking for at least two quarters.

Where to start

Pick the messiest vendor you carry. Get one closed period of (a) the vendor invoice, (b) the vendor usage feed, and (c) your priced partner ledger for that vendor. That is enough to run a shadow reconciliation. The drift surfaces inside an hour. The conversation with the executive team starts from there.

If you'd like to do that on your data, book a 20-minute walk-through and bring the three inputs above. We'll show you what the engine catches.