MERCHANT OF RECORD
Merchant of Record Accounting for SaaS: Sales, Fees, and Net Payouts
Anyway Team
· 9 min read ·
Merchant of Record accounting connects three records: the covered customer order, the MoR settlement report, and the bank payout. Record revenue under the contract and applicable accounting standard, separate fees and refunds, defer subscription revenue when required, then reconcile every payout to order-level activity rather than booking the deposit as unexplained sales.
Anyway supports this flow by acting as MoR for covered transactions, separating tax and fees before net bank payout, and providing order and payment-event data.
The bank deposit is the end of the story, not the start
Suppose a payout reaches the bank on September 3. It may contain August orders, refunds from an earlier period, fees, currency conversion, a withheld amount, or a timing adjustment. The deposit date may also differ from the date the SaaS service was provided.
Booking the full deposit to revenue loses the links needed to answer basic questions:
Which customer orders created the payout?
Which amount represents a service obligation not yet delivered?
Which deductions are MoR fees or refunds?
Which currency and exchange rate apply?
Does a failed or refunded order need an entitlement update?
Merchant of Record accounting starts with the order ledger, then rolls transactions into the payout and general ledger.
Four layers in Merchant of Record accounting
Layer: Customer order; Required record: Order, product, amount, currency, date, status; Purpose: Commercial source record
Layer: Service obligation; Required record: Plan, service period, delivery or entitlement state; Purpose: Revenue timing
Layer: MoR settlement; Required record: Fee, refund, dispute, tax treatment, payout batch; Purpose: Net amount explanation
Layer: Bank and general ledger; Required record: Deposit, functional-currency amount, journal reference; Purpose: Financial close
Anyway provides the covered commercial transaction and net payout path. Your product database supplies the account, workspace, licence, or service-period record. Your accounting system supplies the chart of accounts and reporting policy.
Gross versus net revenue is an accounting judgment
The fact that a provider is called Merchant of Record does not by itself settle the SaaS vendor's gross-versus-net revenue presentation.
Under IFRS 15, when another party is involved in providing goods or services, the entity identifies the specified promise and assesses whether it controls that good or service before transfer. A principal recognizes the gross consideration for the specified good or service. An agent recognizes its fee or commission.
The IFRS guidance points to indicators such as primary responsibility for fulfillment, inventory risk, and discretion in setting price, but the central question is control. Different specified services in the same arrangement can also require separate analysis.
For an MoR arrangement, review:
the agreement between the SaaS vendor and the MoR;
the end-customer terms and named seller;
who promises and controls the SaaS service;
who sets the product price;
who bears refund, credit, and fulfillment responsibilities;
what amount the vendor is contractually entitled to receive.
An accountant may conclude that the vendor presents the SaaS service gross with an MoR fee expense, or that it presents the net amount receivable from the MoR, depending on the facts and accounting framework. Document the conclusion instead of deriving it from the bank payout format.
Transaction tax under an MoR
Anyway states that it is the Merchant of Record for every covered transaction and calculates, collects, and files applicable sales tax, VAT, and GST. The buyer invoice identifies the MoR as the seller, and Anyway sends the vendor net revenue after tax and fees.
This gives the vendor a clean transaction-tax boundary for covered orders. The vendor should retain the agreement and settlement detail that show the MoR's responsibility. Do not create a vendor sales-tax payable merely because the buyer's invoice includes tax charged by the MoR.
The vendor still records its own business income, expenses, and any taxes imposed on its relationship with the MoR or its home jurisdiction. The exact entries belong in the accounting policy set with a qualified adviser.
Revenue timing for subscriptions
Payment timing and revenue timing can differ. An annual subscription paid on August 1 may create twelve months of service. Under a revenue-recognition model based on satisfying the service obligation over time, the unearned portion remains deferred until the service is provided.
Keep these dates separately:
order and payment date;
subscription start and end dates;
cancellation or refund date;
payout date;
accounting period recognized.
Anyway supports recurring subscriptions, including monthly and annual plans. Its payment state can update the product entitlement, while your revenue schedule follows the actual service period and accounting policy.
For a one-time licence, recognition can occur at a point in time or over time depending on the rights granted, updates, support, hosted features, and contract terms. IFRS 15 specifically addresses whether revenue from a licence is recognized at a point in time or over time. Ask your accountant to review the promise, not merely the invoice label.
A practical merchant of record accounting trail from customer order to reconciled payout.
A worked reconciliation example
Assume the following illustrative activity in one payout currency:
Item: Successful product amounts covered by the batch; Amount: $5,000.00
Item: Refunds allocated to those or earlier orders; Amount: ($200.00)
Item: Contractual MoR fees; Amount: ($196.00)
Item: Other documented settlement adjustment; Amount: ($25.00)
Item: Expected net payout; Amount: $4,579.00
The numbers are a teaching example. Your live Anyway records supply the actual order and settlement data used to prove the equation and match the bank deposit.
Revenue recognition is a second calculation. If $2,000 of the product amounts belongs to annual subscriptions with future service periods, part of that amount may remain deferred at month-end even though the cash has already been collected and paid out.
This two-step approach prevents a common mistake: forcing the revenue number to equal the bank number.
Recommended order-level fields
Retain at least:
internal customer and workspace ID;
Anyway order, product, and subscription IDs;
original order timestamp and status;
product amount, transaction currency, and buyer document reference;
service start and end dates;
fee and refund detail;
payout batch and bank date;
functional-currency amounts and exchange-rate source;
general-ledger journal ID;
links to credit notes or dispute records.
Keep raw provider exports immutable. Add transformed accounting fields in a separate table or worksheet so the team can reproduce the close from source data.
Refunds, chargebacks, and credits
A refund can affect cash, revenue, deferred revenue, fees, and product access in different periods. Link it to the original order rather than posting it as a generic negative sale.
For a full refund before service begins, reverse the relevant receivable or revenue and entitlement under the accounting policy. For a refund after partial service, determine how much relates to recognized revenue and how much reduces deferred revenue. A chargeback may follow a different contractual and fee path.
Store both the commercial status and accounting treatment. Anyway's payment events help keep the product state aligned with the covered transaction, while the finance ledger records the approved accounting effect.
Multi-currency treatment
Keep three currency concepts distinct:
the currency shown to and charged to the buyer;
the settlement or payout currency used by the MoR;
the functional currency used in your financial statements.
Retain the original amount even after conversion. Record the exchange-rate source and date used by the accounting policy. Differences between order-date measurement, settlement conversion, and bank receipt may create exchange gains or losses.
Do not overwrite original transaction values with a converted number. The buyer invoice, provider report, and ledger should remain traceable to one another.
Anyway pricing in the ledger
For ledger planning, Anyway lists one Business transaction price: 3.9% + $0.50. The public plan has no monthly or setup fee. At a $100 transaction amount used for fee modeling, the published formula produces $4.40.
Create a specific MoR-fee account if the accounting policy presents the product revenue gross. If the policy presents revenue net, retain the fee detail in the subledger even when it does not appear as a separate income-statement expense. This preserves unit-economics analysis and contract verification.
Use the current agreement and settlement report as the source for the actual fee base, rounding, currency treatment, refunds, and adjustments.
Merchant of Record accounting month-end checklist
Lock the provider report cut-off and time zone.
Import successful, pending, failed, cancelled, refunded, and disputed orders.
Deduplicate by event and order ID.
Connect each order to its product and service period.
Apply the documented gross-or-net accounting policy.
Calculate recognized and deferred revenue.
Post fees, refunds, credits, disputes, and exchange differences.
Roll transactions into each payout batch.
Match every batch to the bank statement.
Investigate differences rather than posting them to revenue.
Save the source files, transformation logic, journal, and reviewer sign-off.
Frequently asked questions
What is Merchant of Record accounting?
It is the process of recording the vendor's economic relationship with an MoR, connecting customer orders and service periods to MoR fees, refunds, settlement reports, and net bank payouts.
Should I record the net payout as revenue?
Not automatically. Revenue presentation and timing depend on the contract, specified goods or services, control assessment, and applicable accounting standard. The bank deposit is a settlement amount, not the accounting policy.
Is an MoR fee an expense?
It may be a separate expense when the vendor presents revenue gross. Under a net presentation, the fee may be reflected in the net revenue amount. Keep the fee detail in either case.
Do I record sales tax collected by Anyway as my tax payable?
Anyway is the seller for covered transactions and states that it collects and files applicable transaction tax. Retain the contract and settlement evidence, then apply the accounting policy advised for your jurisdiction.
How should I account for an annual SaaS plan?
Payment can arrive before the service is delivered. The amount may need to be recognized over the service period, with the undelivered part recorded as deferred revenue under the applicable standard and contract facts.
What does Anyway provide for reconciliation?
Anyway provides covered order and payment state, separates tax and fees before payout, and sends net revenue to the seller's bank account. The seller can connect those records to its product account and accounting ledger.
Build the ledger from the first order
Create an Anyway product, process a real low-value order, and preserve the complete path from checkout to entitlement, invoice, settlement detail, and bank payout.
Official sources checked
Information checked on August 26, 2026. This is an operating framework, not accounting, legal, or tax advice. Apply the standards and contract terms relevant to your business.