Your company just closed its first $200,000 deal through AWS Marketplace. The sales team is celebrating. The VP of Sales is updating the board deck. And your finance team is quietly panicking — because nobody told them how marketplace revenue actually hits the books.

Cloud marketplace revenue recognition is the dark corner of SaaS finance that almost nobody talks about until it creates a problem. When that problem surfaces, it usually surfaces at the worst possible moment: during a board review, an acquisition due diligence process, or an audit.

This guide is written to prevent that moment.

Whether you are a VP of Finance at a Series B startup or a controller at a mid-market software company, what follows is a practical, plain-language walkthrough of how cloud marketplace transactions work from an accounting perspective — and what you need to get right from day one.

Why Marketplace Revenue Is Different

When a customer buys your software directly, the accounting is relatively straightforward. You invoice them, they pay you, and you recognize revenue over the term of the contract in accordance with ASC 606.

The cash flow is predictable, the counterparty is clear, and your accounts receivable ledger reflects reality.

Marketplace changes that picture in three important ways:

• You are not the seller of record. AWS, Microsoft, or Google is. The cloud provider collects payment from the customer and remits a portion to you.
• There is a fee taken off the top. Depending on the marketplace and program, the cloud provider keeps between 3% and 15% of the transaction value before disbursing your share.
• Payment terms are set by the marketplace. You do not invoice the customer on your terms. The cloud provider pays you on a schedule — typically net 45 to net 60 from the end of the month in which the transaction closed.

Each of these differences has accounting implications. Let's work through them systematically.

Gross vs. Net Revenue: The Most Important Question

The first question your auditors will ask about marketplace revenue is whether you are recognizing it gross or net. This is not merely a presentation question — it affects your top-line revenue, your gross margin, and potentially your valuation multiples.

The Principal vs. Agent Framework

Under ASC 606, whether you recognize gross or net revenue depends on whether you are acting as a principal or an agent in the transaction. The determination hinges on who controls the specified good or service before it is transferred to the customer.

If you are the principal, you recognize the full transaction price as revenue and the marketplace fee as a cost of revenue. If you are the agent, you recognize only your net share (after the marketplace fee) as revenue.

For most software ISVs selling through cloud marketplaces, the analysis lands on gross revenue recognition, because:

• You control the software product. The cloud provider is a distribution channel, not the entity delivering the software to the customer.
• You bear the primary responsibility for fulfillment. If the product fails to perform, the customer relationship and the obligation to remedy falls to you.
• You set the price. Even though the transaction is processed by the marketplace, you establish the list price, private offer terms, and discounting.
• You bear inventory risk (to the extent applicable to software). You are responsible for maintaining the product and ensuring it functions as described in the listing.

That said, this is a judgment call that should be made with your auditors. There are edge cases — particularly for resale arrangements or where the cloud provider has meaningful involvement in delivering the service — where net recognition may be appropriate.

Document your analysis and your rationale.

What Gross Recognition Looks Like in Practice

Assume a customer signs a $100,000 annual contract through AWS Marketplace. AWS charges a 3% fee under its standard program, so you receive $97,000.

Under gross revenue recognition:

• Revenue recognized: $100,000 (over the contract term, per your performance obligations under ASC 606)
• Marketplace fee: $3,000 (recorded as cost of revenue)
• Net cash received: $97,000

Under net revenue recognition:

• Revenue recognized: $97,000 (only your net share)
• No separate cost of revenue line for the marketplace fee

The difference matters enormously for top-line comparisons, ARR calculations, and gross margin presentation. If your company reports ARR using recognized revenue as the numerator, the choice between gross and net recognition will affect that number directly.

Marketplace Fees as Cost of Revenue

Assuming you recognize marketplace revenue gross, the marketplace fee belongs in cost of revenue — not in operating expenses, and not netted against revenue.

This classification is important because it flows directly into your gross margin calculation. If your direct sales carry no comparable fee, your blended gross margin will appear slightly lower as marketplace revenue becomes a larger share of the mix.

This is expected and explainable, but it needs to be communicated clearly to your board and investors so that the margin compression is understood as a channel cost, not a product deterioration.

Some CFOs prefer to break out marketplace fees as a separate line item within cost of revenue — for example, "cloud marketplace fees" — rather than lumping them with hosting costs or professional services. This approach gives you cleaner visibility into channel economics and makes board discussions more straightforward.

Tracking Fees by Marketplace

If you are selling on multiple marketplaces simultaneously — AWS, Azure, and GCP — you will want to track fees by marketplace in your general ledger or at minimum in a supporting schedule. Fee rates differ across providers and programs, and the ability to analyze channel profitability by marketplace is valuable for GTM decisions.

A simple approach is to create sub-accounts within your cost of revenue for each marketplace (e.g., "Cost of Revenue - AWS Marketplace Fees," "Cost of Revenue - Azure Marketplace Fees") and post the fee amounts to the appropriate sub-account when you receive the remittance statement from each provider.

ASC 606 Implications for Marketplace Contracts

ASC 606 requires you to recognize revenue when (or as) performance obligations are satisfied. For most SaaS products sold through cloud marketplaces, the performance obligation is the ongoing right to access the software — a service delivered continuously over the subscription term.

This means you recognize revenue ratably, on a straight-line basis, over the contract period.

Marketplace contracts introduce a few wrinkles worth understanding.

Contract Commencement Date

The contract commencement date for a marketplace deal is typically the date the customer accepts the offer in the marketplace — not the date your internal CRM shows the deal as "closed won." Make sure your revenue recognition start date is anchored to the actual marketplace acceptance event, which is documented in the marketplace's order management system.

Multi-Year Deals Paid Upfront

Some customers pay for multi-year contracts upfront through their committed cloud spend (for example, an AWS DRAW or Azure MACC commitment). In this case, you receive (or are entitled to receive) the full multi-year contract value early, but you still recognize revenue ratably over the full term.

The difference between cash received and revenue recognized should be reflected as deferred revenue on your balance sheet.

Usage-Based and Metered Contracts

If your marketplace listing includes metered pricing — where customers pay based on consumption rather than a fixed fee — revenue recognition becomes variable and must be estimated or recognized as usage is consumed. Under ASC 606, variable consideration is included in the transaction price to the extent it is probable that a significant reversal will not occur.

For consumption-based marketplace products, this often means recognizing revenue in the period in which the usage occurs, once the marketplace has confirmed the meter readings.

Contract Modifications

Marketplace customers can amend their contracts — adding seats, changing tiers, or extending terms. Each modification needs to be evaluated under ASC 606 to determine whether it represents a separate contract or a modification of the original contract.

The treatment affects how you recognize revenue on the incremental value and whether you need to catch up or spread the change prospectively.

Accounts Receivable and the Marketplace as Intermediary

One of the more confusing aspects of marketplace accounting is the accounts receivable treatment. When you sell through a marketplace, your counterparty for collection purposes is the cloud provider, not the end customer.

The customer pays the cloud provider; the cloud provider remits to you.

This means your accounts receivable ledger should reflect amounts owed to you by the cloud provider, not by the end customer. At the end of each reporting period, you should accrue marketplace receivables for any revenue recognized that has not yet been remitted by the provider.

In practice, this requires you to reconcile the marketplace's remittance schedule against your revenue recognition schedule monthly. Most cloud providers publish remittance statements in their seller portals (AWS Marketplace's Seller Reports, Azure Marketplace's payout statements, GCP Marketplace's billing exports), and those statements should be the primary source of truth for what you have earned and when you will be paid.

Reporting Marketplace Revenue to Your Board

Board members and investors increasingly understand that cloud marketplace revenue is a distinct channel with its own economics. Presenting it clearly — and separately from direct sales — demonstrates financial sophistication and helps the board understand your channel mix and its implications.

A strong marketplace revenue section in a board package typically includes:

• Total marketplace ARR (gross, by cloud provider)
• Net marketplace ARR (after fees, showing blended effective fee rate)
• Marketplace as % of total ARR (trend over trailing 4 quarters)
• New marketplace bookings in the quarter
• Pipeline from co-sell motions (AWS ACE, Microsoft co-sell, GCP PSO)
• Gross margin impact (explaining the marketplace fee as cost of revenue)
• Payment terms and AR aging for marketplace receivables

A simple table showing the fee waterfall on your largest marketplace deals is often the most effective tool for grounding board members in the economics. Walk them through a $100K deal: $100K contract value, minus $3K to $5K in marketplace fees, equals $95K to $97K net to you — with cash arriving 45 to 60 days after month end.

Once they see that structure once, they understand the model for every subsequent deal.

Reconciliation Challenges and How to Address Them

The most common operational headache in marketplace accounting is reconciliation — matching what the marketplace reports you earned against what your CRM or billing system shows as contracted.

The challenge arises because:

• The marketplace processes the transaction independently and may record the deal date differently than your CRM
• Metered usage is reported by the marketplace on a lag
• Private offer amendments may not sync cleanly with your billing system
• Currency conversions (for international marketplace transactions) can introduce rounding differences

Building a Reconciliation Process

A practical reconciliation process for marketplace revenue involves three steps performed monthly:

1. Pull the marketplace remittance statement for the prior month from each cloud provider's seller portal. This is the source of truth for what the provider recognized and what it owes you.
2. Map each marketplace transaction to a CRM deal or contract record. Most companies use the marketplace offer ID or the customer's cloud account ID as the linking key. Any transactions that do not match should be investigated immediately.
3. Reconcile recognized revenue against deferred revenue and AR balances. The sum of marketplace revenue recognized in the period, plus changes in deferred revenue, should equal the total contract value activated in the period per the marketplace statement.

If you are selling on multiple marketplaces simultaneously, run this reconciliation separately for each provider. Mixing AWS and Azure remittance data before reconciling will make errors nearly impossible to isolate.

Tax Considerations

Cloud marketplace transactions may have different tax treatment depending on the jurisdiction and the structure of the deal. In the United States, AWS, Microsoft, and Google act as the merchant of record and handle sales tax collection and remittance on marketplace transactions in states where they have an obligation to do so.

This simplifies your sales tax compliance burden significantly compared to direct sales.

However, for international transactions — particularly in the EU and UK where VAT applies — the principal-agent analysis may affect who is responsible for VAT. Work with your tax counsel to understand the implications for international marketplace sales before you scale that channel.

Where Automatum Fits In

One of the practical challenges finance teams face when first going live on cloud marketplaces is that the operational data — offers created, deals closed, fees charged, remittances received — lives entirely inside the cloud provider's seller portal. Pulling that data into your financial systems for recognition, reconciliation, and reporting typically requires manual exports, spreadsheet assembly, and a lot of judgment about what belongs where.

Automatum is the platform ISVs use to manage their cloud marketplace presence across AWS, Azure, and GCP from a single interface. Beyond listing management and private offer creation, Automatum gives finance teams visibility into the marketplace data that matters for accounting: deal values, offer terms, marketplace fee rates, and revenue by provider.

That visibility — alongside the deal workflow data your sales team is already using — makes the monthly reconciliation process significantly less painful and significantly less error-prone.

For companies scaling marketplace revenue quickly, having a unified platform that connects deal creation to financial reporting is not a nice-to-have. It is the difference between a finance team that is always catching up and one that can close the books on marketplace revenue with confidence.

Getting This Right From Day One

The companies that struggle most with marketplace revenue recognition are the ones that treated it as a footnote to their direct sales process — "it's just another deal, we'll figure out the accounting later." When marketplace revenue reaches 20%, 30%, or 50% of ARR, "we'll figure it out later" becomes a serious audit risk.

The companies that do it well establish their gross vs. net determination, their cost of revenue classification, and their reconciliation process before their first deal closes. They treat marketplace as a distinct channel in their chart of accounts, their revenue recognition policy, and their board reporting from the very beginning.

If your company is preparing to list on AWS, Azure, or GCP Marketplace — or if you are already live and realizing the accounting setup needs work — now is the time to get it right. The market is moving fast, committed spend is becoming the default procurement path for enterprise software, and marketplace revenue is only going to grow as a share of SaaS company revenue.

Make sure your finance team is ready for it.