Cloud Reseller and CSP Billing Software: Where Margin Disappears Between the Vendor File and the Invoice

Why reselling cloud quietly erodes the margin you thought you priced

The reconciliation file from the vendor portal lands on the sixth. It has several hundred thousand rows covering every tenant, every subscription, every seat change and every partial period in the month just closed. Next to it sits the file from a second vendor, in a different layout, in a different currency, covering a period that runs from the twelfth to the eleventh because that is when the customer's term started. A third vendor sends a summary that does not break down by tenant at all. Your billing coordinator opens a workbook, starts matching, and disappears for four working days.

What she is really doing is answering one question the business cannot otherwise answer: for each customer, what did we pay and what did we charge. Nobody in a reselling business is short of revenue numbers. What they are short of is margin at the line level, in the month it happened, before the quarter closes and the answer stops being actionable. So resellers price on assumption, discover in aggregate that the blended margin drifted, and cannot say which customers or which products caused it.

The erosion happens in small, repeated ways. A customer reduced seats and the reduction never reached the vendor subscription, so you keep paying for licences you stopped billing. A promotional rate expired at the vendor and the customer price did not move. A mid month upgrade was prorated one way by the vendor and another way on your invoice. A currency moved between the vendor's conversion date and yours. A quarterly incentive that you assumed in your pricing was not earned because a threshold was missed. None of these is large. All of them recur every month across every customer, which is precisely the definition of a problem worth automating.

Problem one: the vendor's billing period is not your billing period

This is the structural issue underneath most reseller billing pain. Customer subscription terms start on the day the customer bought, so anniversaries scatter across the calendar. Your invoice run is monthly, on a date you chose. The vendor's reconciliation period is their own. Once seats change mid period, and they always do, correct billing becomes a per day calculation on both sides, and any system that thinks in whole months will be wrong by a small amount on a large number of lines.

Microsoft's New Commerce Experience made this sharper for anyone in the CSP channel, because term commitments are now fixed with seat reductions only permitted inside a short cancellation window at the start of the term. That changes the commercial risk: if you let a customer reduce seats mid term on your invoice, you carry the vendor cost for the remainder yourself. A billing system that does not understand the difference between what the customer may change and what the vendor will accept is not a billing system, it is a margin leak with a user interface.

A custom build makes the subscription the object that carries both sides: the vendor term with its commitment rules and end date, and the customer commercial terms with your own cancellation policy. Any requested change is validated against both before it is accepted, and where they conflict the system tells your account manager what the change will cost the business before they promise it to the customer.

Problem two: every vendor file is a different file and they change without notice

Multi vendor resellers deal with productivity suites, infrastructure, backup, security, communications and increasingly niche software vendors, each with their own export format, identifier scheme, currency handling and delivery mechanism. Some have proper partner APIs. Some produce a report you download. Some email a spreadsheet. Identifiers rarely match across systems, so the same customer is a tenant identifier in one, an account number in another, and a name spelled slightly differently in a third.

The engineering answer is a normalisation layer with a per vendor adapter and a mapping table between vendor entities and your customer records, plus enough tolerance that a schema change breaks one adapter rather than the whole run. Just as important, and often skipped, is a reconciliation report that runs before invoicing rather than after: every vendor charge that did not map to a customer subscription, and every customer subscription that had no vendor charge. Those two lists are where the money is. In our experience the second list is the more shocking of the two, because it is subscriptions you are still paying for.

Problem three: your margin is not known when you send the invoice

Resellers earn from several sources that arrive at different times. There is the difference between your buy price and sell price, which is known immediately. There is a tier discount that depends on volume across your whole book. There are incentives and rebates paid in arrears against programme conditions, often quarterly. There may be a services component you sell alongside the licence with its own cost of delivery. The invoice margin and the true margin are therefore different numbers, and pricing decisions made against the first one are guesses.

What a build should do is carry both explicitly: recognised margin at invoice, plus accrued programme earnings estimated against the conditions you expect to meet, then trued up when the vendor statement arrives. Once that exists you can ask the question that actually matters, which is margin per customer after everything, including the support hours that particular customer consumes. Many resellers discover at that point that a handful of accounts they consider strategic are net negative once support is loaded in, and that the boring accounts nobody talks about are funding the business.

Problem four: bundles hide the economics

Almost nobody sells a raw licence any more. The commercial product is a managed seat that includes the productivity licence, a backup subscription, an endpoint security agent, and your own monitoring and helpdesk. The customer sees one price per user per month. The cost is assembled from four vendors on four different terms plus internal labour.

Off the shelf reseller platforms model bundles, but usually as a fixed composition priced as a unit. The reality is messier: a bundle whose composition changed in March, customers grandfathered on the old composition at the old price, one component whose vendor cost rose mid term, and a large customer with a negotiated variant. Handling that requires bundle definitions to be versioned with effective dates and customers to be pinned to a version, which is a data model decision that has to be made at the start. Retrofitting versioning onto a bundle model after go live is one of the more painful pieces of work in this category, and we have been called in to do it more than once.

What this costs and how long it takes

A first release covering vendor ingestion for your top three or four programmes, subscription and term modelling with day accurate proration, markup and bundle rules, invoice generation and margin per customer runs $65,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding provisioning and deprovisioning callbacks to vendor APIs, incentive and rebate accrual, multi currency and multi entity, payment collection with dunning, a customer self service portal, and accounting integration runs $150,000 to $400,000 over 6 to 12 months.

The specific cost drivers here: how many vendor programmes and how many of them have real APIs rather than downloadable reports, since a portal scrape or manual upload path costs more to build and far more to maintain. Whether you provision as well as bill, because writing back to vendor APIs to create and cancel subscriptions turns a billing system into an operational one with a much higher bar for error handling. Multi currency, which sounds small and is not, because the conversion date policy has to be agreed with your accountant and applied consistently across the vendor cost and the customer charge. And whether you are a distributor with resellers underneath you, which adds a whole tier of pricing and statement generation.

Build versus buy, and when buying is right

Buy if you resell one or two vendor programmes to under about 100 tenants with simple markup. Work 365 is strong specifically in the Microsoft CSP context if you already live in Dynamics, and Cloudmore covers mid market multi vendor reselling well. Either will cost you a fraction of a build and get you further than a spreadsheet immediately. CloudBlue and AppDirect are the serious platform options if you are running a genuine marketplace with third party vendors onboarding to sell through you, though both are substantial programmes to implement rather than tools you switch on.

Build when your bundle and pricing logic has outgrown what a product catalog can express, when you have vendor programmes without clean APIs that need bespoke ingestion anyway, when your margin question requires joining billing data to your own support and delivery costs, or when the monthly reconciliation has become a named person's full time job. That last one is the usual trigger, and the honest way to size the business case is to add that person's time to whatever the pre invoice reconciliation report turns up in unbilled and over purchased subscriptions.

How to choose a developer for reseller billing

Ask how they would handle a customer who reduces seats mid term on a vendor commitment that does not allow reduction. The answer should be about validating the change against both sides and surfacing the cost to the account manager, not about processing the change. Anyone who treats the customer request as the source of truth has not worked in this channel.

Ask how bundles are versioned and how a customer stays on the composition they bought. Ask what happens when a vendor changes their export schema without notice, since that is a monthly reality rather than an edge case, and the design should isolate the failure to one adapter with an alert rather than a failed invoice run. Ask what their reconciliation report shows before invoicing, because a developer who has done this will immediately talk about unmatched vendor charges and orphaned subscriptions.

Agree code and infrastructure ownership in writing before kickoff, including repository and cloud accounts. At Digital Heroes the client owns the code from the first commit. A first step that costs one afternoon: take last month's vendor files and your invoice run, and list every vendor charge with no matching customer line. Whatever that list totals, annualised, is the floor of your business case.