AWS Marketplace Seller Bookkeeping: Reconcile Gross Revenue, Listing Fees, Taxes, Refunds, and Delayed Disbursements by Offer

Your AWS Marketplace sales can be growing while your bank feed still looks inexplicably small. That is not necessarily a pricing problem. It is often a reporting problem: the customer is billed on one date, AWS collects the invoice later, fees are deducted, tax may be handled under a different scenario, and the resulting cash arrives in a later bank statement.

For a software company selling through AWS Marketplace, the deposit is the final result of several events—not the sale itself. A reliable bookkeeping process preserves the gross transaction, records the marketplace fee and tax treatment, tracks refunds, and then reconciles the net disbursement to the bank. Once those layers are separated, your margin, revenue, receivables, and cash forecast become much easier to trust.

Why AWS Marketplace deposits do not equal revenue​

The most common mistake is booking each bank deposit as sales income. That shortcut hides four questions:

• What did the customer actually buy, and under which offer?
• How much did AWS deduct as a listing fee?
• Was tax collected by AWS, collected and passed to you, or left for you to calculate and remit?
• Which invoices, refunds, credits, and prior-period activity make up this particular deposit?

AWS Marketplace reporting gives you the components needed to answer those questions. The collections and disbursement dashboard distinguishes gross revenue, gross refunds, listing fees, listing-fee refunds, seller tax share, AWS tax share, seller net revenue, and disbursement details. It also provides invoice IDs, offer IDs, agreement IDs, transaction references, and bank trace IDs that can be used to connect the operational reports to your accounting records.

The result is an important accounting principle: record the economic activity at the transaction level, then use the deposit as a reconciliation target. Cash is evidence that money moved. It is not enough evidence to explain why it moved.

Build a chart of accounts for the marketplace flow​

You do not need a separate account for every customer, but you do need enough structure to keep platform activity visible. A useful starting point is:

Revenue and contra-revenue​

• AWS Marketplace gross revenue
• AWS Marketplace refunds and credits
• Discounts or contract concessions, if they are not already reflected in the gross report amount

If your business recognizes revenue over a SaaS contract term, keep the marketplace billing event separate from the revenue-recognition schedule. The Marketplace invoice date and the service period may not be the same accounting date.

Clearing and balance-sheet accounts​

• AWS Marketplace receivable or undisbursed collections
• AWS Marketplace disbursement clearing
• Customer deposits or deferred revenue, where applicable
• Refunds payable or refund clearing
• Sales-tax or VAT payable, separated by jurisdiction if your tax process requires it

Expenses and deductions​

• AWS Marketplace listing fees
• VAT or other tax charged on listing fees, where applicable
• Channel-partner or wholesale costs for offers that include a reseller
• Bank fees or foreign-exchange differences, if they appear between disbursement and settlement

The exact account names are less important than consistency. Your bookkeeping system should make it possible to answer, “How much gross Marketplace revenue did we generate this month, how much remains undisbursed, and what did the platform retain?” without reconstructing the answer from a single net deposit.

Use offer-level dimensions, not just one Marketplace total​

AWS Marketplace may contain public offers, private offers, enterprise agreements, SaaS contracts, usage-based products, and channel partner private offers. Their pricing, timing, fees, taxes, and renewal behavior can differ.

Track at least these dimensions in your sales or journal-import process:

• Product title and product ID
• Offer ID and offer visibility
• Agreement ID
• Customer or payer identifier
• Invoice ID and invoice date
• Usage period start and end dates
• Currency
• Seller-of-record or facilitating entity, when relevant

Offer ID is especially useful for pricing analysis. If one private offer contains a negotiated discount or a different payment schedule, combining it with public-listing revenue can make a healthy offer look unprofitable—or hide a genuinely weak one.

Agreement ID is useful for contract continuity. An upgrade, renewal, or amendment can replace pending payment terms even though existing invoices remain unchanged. That means a change in the current agreement does not automatically rewrite history in your books.

The journal-entry pattern: gross first, cash later​

The following example uses simple numbers to show the flow. Suppose a public SaaS offer produces $10,000 of gross billings in a period, and the applicable listing fee is 3%. Ignore taxes, refunds, and foreign-exchange effects for the moment.

At the billing or earned-revenue stage, record:

Dr AWS Marketplace receivable       10,000
    Cr AWS Marketplace revenue                   10,000

When the listing fee is recognized or deducted from the settlement:

Dr AWS Marketplace listing-fee expense   300
    Cr AWS Marketplace receivable                    300

When AWS collects and disburses the balance:

Dr AWS Marketplace disbursement clearing  9,700
    Cr AWS Marketplace receivable                    9,700

When the bank deposit appears:

Dr Operating bank account                9,700
    Cr AWS Marketplace disbursement clearing        9,700

In real books, the entry timing depends on your revenue-recognition policy, accounting basis, legal entity, and tax treatment. The pattern matters because it keeps the fee visible. Booking only the $9,700 deposit as revenue would understate gross sales and make the listing fee disappear into an unexplained reduction of income.

AWS’s listing-fee schedule varies by product and offer type. For example, AWS documents different standard rates for SaaS, server products, data offers, private offers, channel-partner private offers, and professional services. Do not hard-code one percentage into your accounting automation. Import the reported fee amount and retain the reported percentage as a check.

Treat taxes as a scenario to identify, not a guess to make​

Marketplace tax handling depends on the buyer’s tax address, product type, seller location, and marketplace-facilitator rules. The billing-event data can distinguish at least three broad patterns:

1. AWS collects and remits the tax. This is represented as an AWS tax-share event and does not increase the amount disbursed to the seller.
2. AWS collects the tax, includes it in the seller’s settlement, and the seller remits it. This is represented as a seller-tax-share event.
3. AWS does not calculate or collect the tax, leaving the seller responsible for calculating and remitting it.

These patterns are not interchangeable. If a tax amount is merely informational and does not affect the seller balance, do not add it to sales or cash. If tax is disbursed to you, route it to a tax-payable account rather than revenue. If the seller is responsible for tax that AWS never collected, create a liability through your own invoicing or tax engine and reconcile it outside the Marketplace deposit.

Keep the tax evidence with the transaction. Store the buyer geography, product, offer, invoice, tax-share type, amount, and filing jurisdiction—or a reference to the report containing those fields. A tax summary without transaction-level support is difficult to defend and difficult to correct.

Reconcile refunds and credits to the original offer​

Refunds are not just negative bank deposits. They can reverse gross revenue, reverse a listing fee in part, reduce a tax amount, and change a future disbursement. AWS refers to refunds as billing adjustments in parts of the seller workflow, and a cancellation does not necessarily cancel invoices that have already been issued.

For every refund or credit, capture:

• The original invoice ID
• The billing period
• The product ID and offer ID
• The agreement or subscriber reference
• The refund amount and reason
• Whether the listing fee and tax shares were also reversed
• The date the adjustment was invoiced, collected, or disbursed

Then apply the adjustment to the same revenue, fee, and tax accounts used for the original transaction. If you post all refunds to a generic “refund expense” account, your product margin will be distorted and your revenue reports will disagree with AWS’s gross and net fields.

Contract cancellations deserve special care. A cancellation changes the agreement status, while a billing adjustment changes an invoice or returns funds. If both are needed, track both actions and link them to the affected invoice lines.

Make the monthly disbursement reconciliation mechanical​

Use a repeatable close checklist rather than downloading a report only when the deposit looks wrong.

1. Freeze the reporting period​

Choose whether the close is based on invoice date, usage period, collection date, or disbursement date. These are different views. A disbursement report for a month can contain invoices billed earlier, while a revenue report for the same month can contain invoices that have not yet been collected.

2. Import the detailed report​

Bring in the invoice, offer, agreement, gross revenue, refunds, fee, tax, currency, disbursement status, disbursement date, and bank-trace fields. Preserve the original report file or an immutable export reference.

3. Group by transaction reference​

Use the transaction reference ID or related billing-event identifiers to avoid double-counting the invoice, fee, tax, refund, and disbursement rows that belong to one transaction family. A spreadsheet pivot or a small scripted import can expose duplicated line items quickly.

4. Tie undisbursed balances to open receivables​

The collections dashboard separates collected and disbursed funds from open and unpaid invoices. Compare the undisbursed balance with your AWS Marketplace receivable. Investigate old balances by payment terms, customer, offer, and invoice age rather than treating every delay as a bank problem.

5. Match net disbursement to the bank​

Match the report’s disbursement amount and bank trace ID to the bank deposit. If the amount differs, look for ACH timing, currency conversion, failed disbursement, refund activity, fee invoices, or a balance adjustment before posting a plug.

6. Review exceptions by offer​

Look for offers with unusually high refunds, long collection times, negative net revenue, unexpected tax shares, or listing-fee percentages that differ from the expected contract terms. These are operating signals, not just bookkeeping cleanup.

Common mistakes that make the numbers unreliable​

Posting the deposit as gross revenue​

This hides fees and makes revenue-to-cash reconciliation impossible. Use a clearing account and book the gross-to-net bridge.

Mixing customer invoice date with cash date​

This creates artificial month-to-month volatility and can misstate receivables. Keep invoice, collection, disbursement, and service-period dates distinct.

Treating all tax-share fields as tax payable​

Some tax amounts are collected and remitted by AWS and do not affect your balance. Classify by transaction type and jurisdiction.

Ignoring private offers and amendments​

Private offers can have negotiated pricing and payment schedules. Store the offer and agreement identifiers so a renewal or amendment does not get merged into the wrong product cohort.

Using a generic refund account​

Reverse the original revenue, fee, and tax components where appropriate. The refund should explain the original transaction, not merely reduce profit somewhere else.

Letting the bank feed become the source of truth​

The bank can confirm settlement, but it cannot tell you which customer, offer, invoice, tax scenario, or listing fee produced the cash. Reconcile the bank against the Marketplace report, not the other way around.

Turn the reconciliation into a management report​

Once the entries are structured, calculate useful operating metrics by product and offer:

• Gross Marketplace billings
• Net revenue after listing fees and refunds
• Refund rate by offer
• Average days from invoice to collection and disbursement
• Undisbursed receivables by aging bucket
• Marketplace fee rate as a percentage of gross revenue
• Tax collected for the seller versus tax remitted by AWS
• Cash conversion by currency and customer segment

A dashboard can show these trends, while the underlying plain-text ledger keeps the calculation auditable. If you use Beancount, linking each transaction to an invoice, offer, or report identifier makes later review much faster. A visualization layer such as Fava can then help you explore balances and dimensions without turning the source records into a black box. For technical users, the documentation provides a natural place to standardize import and reconciliation workflows.

Simplify Your Financial Management​

AWS Marketplace becomes easier to manage when every deposit can be traced back to gross revenue, fees, taxes, refunds, and offers. Beancount.io offers plain-text accounting that is transparent, version-controlled, and AI-ready, so your financial data remains reviewable as your sales channels multiply.