Yes. A marketplace can record accrued revenue before buyer cash arrives when performance obligations are satisfied under accrual accounting. The practical sequence is to book an adjusting journal entry for earned but unbilled activity, then move that balance to accounts receivable once invoiced, without adding new revenue. To keep close quality intact, require evidence for each trigger and run a period-end tie-out across accrued, billed, and deferred states.
You can recognize revenue in a two-sided marketplace before buyer cash arrives, but only if you separate the earning event from billing and make the reclass path explicit. The practical job is to design the accounting so your finance, ops, and product teams can record revenue early without losing control of reconciliation. If you cannot explain that path clearly, your close team will feel it at month end.
At the core, accrued revenue is income earned before payment is received. Under accrual accounting, revenue is recognized when goods or services are delivered, not when cash is collected. In marketplace operations, buyer payment timing, invoice timing, and revenue recognition can land on different dates. If those dates blur together, close quality can suffer.
This guide is about accounting design, not legal advice or a jurisdiction-specific conclusion. The goal is narrower. Define when revenue is earned, decide what should be posted before invoicing, and make sure your ledger still ties out once billing and collection catch up. In plain terms, you need one consistent rule for when an earned service becomes an accounting entry, and another for what changes when the invoice is finally issued. We recommend locking that rule before your team automates invoicing or reclass logic.
The journal mechanics are simple. The control points are where teams usually get into trouble. Before invoicing, a pre-billing adjusting journal entry can debit an accrued revenue asset and credit revenue. After invoicing, accounts receivable appears because payment is now due. The earlier accrual needs a documented reversal or reclass pattern so revenue is not counted twice. One of the first checkpoints at period end should be a tie-out between earned-event records, invoices issued after close, and any accrued balances still left open.
That matters because month-end reconciliation is the formal accuracy check at close, and timing gaps do not stay small for long. Small breaks can distort reporting, delay close, and increase audit risk. In a marketplace context, they can also create friction between finance records and operational decisions.
The guide follows four steps:
Get those four pieces right, and recognizing revenue before cash arrives becomes a controlled accounting choice instead of a month-end guessing exercise. We would rather see your team prove one clean close cycle than automate a rule it cannot explain. For related reading, see Marketplace Subscription Monetization: How to Add Recurring Revenue.
Before the first posting, align policy, ownership, evidence, and close review so everyone uses the same earned-event definition.
| Preparation area | What to set up | Review check |
|---|---|---|
| Recognition policy | What "earned" means, how that aligns with accrual accounting, the customer contract, the performance obligations, and the event that shows those obligations were met | If two reviewers choose different earned dates for the same transaction, the policy is still too vague |
| Posting-state ownership | Ownership for the earned-event source, invoice creation, and the journal/reclass to billed status | Each state needs a named owner and a clear handoff trigger |
| Evidence pack | Contract terms, fulfillment or event record, invoice status, and the period cutoff rule used for the close | Tie the pack to the specific performance obligation so reviewers can trace why recognition was triggered |
| Close packet | Expected revenue impact, accrued revenue movement, and the later change when billed status creates A/R | If accrued-versus-billed movement is not clear, fix the workflow before live posting |
Define what "earned" means under your GAAP policy, how that aligns with accrual accounting, and how your team applies the revenue recognition principle in this marketplace model. Anchor it to the ASC 606/IFRS 15 core idea of depicting the transfer of promised goods or services, then state the customer contract, the performance obligations, and the event that shows those obligations were met. Verification point: if two reviewers choose different earned dates for the same transaction, the policy is still too vague.
GAAP does not prescribe your org chart, but management is responsible for internal control over financial reporting, so handoffs should be explicit. Define ownership for the earned-event source, invoice creation, and the journal/reclass to billed status. If a transaction can move through "earned," "billed," and "collected," each state needs a named owner and a clear handoff trigger. We recommend naming that owner in the same workflow your reviewers already use.
Standards do not mandate your artifact format, so define it internally. For each trigger, keep the contract terms, fulfillment or event record, invoice status, and period cutoff rule used for the close. Tie the pack to the specific performance obligation so reviewers can trace why recognition was triggered.
Because adjusting entries affect at least one income statement account and one balance sheet account, show both views together in the close packet. Include expected revenue impact, accrued revenue movement, and the later change when billed status creates A/R. A practical checkpoint is a mock close with sample transactions; if accrued-versus-billed movement is not clear, fix the workflow before live posting.
For a related angle, see Building Subscription Revenue on a Marketplace Without Billing Gaps.
Use a binary rule: recognize revenue only when the contract's performance obligations are satisfied. If they are not satisfied, do not post, even when collection risk looks low.
| Scenario | Recognition response | Grounding |
|---|---|---|
| Promised good or service is transferred to the customer | Recognize revenue when the performance obligations are satisfied | The earned date should follow delivery evidence, not invoice timing or cash receipt timing |
| Payment looks likely but obligations are not satisfied | Do not post | "Likely to pay" is not the same as "earned" |
| Obligation is satisfied over time | Recognize revenue based on progress and hold the unearned balance | Do not front-load the full amount into one current-asset entry at transaction start |
| It is unclear whether the platform controls the specified good or service before transfer | Pause posting and resolve the principal-versus-agent assessment first | Treat role ambiguity as a policy decision before close |
Revenue is earned when the promised good or service is transferred to the customer, so your posting should tie to contract terms and fulfillment evidence. The earned date should follow delivery evidence, not invoice timing or cash receipt timing.
Under accrual accounting, delivery drives recognition and payment timing does not. In marketplace operations, "likely to pay" is not the same as "earned." If your team blurs those ideas, you can end up recognizing confidence instead of revenue.
When an obligation is satisfied over time, recognize revenue based on progress and hold the unearned balance. Do not front-load the full amount into one current-asset entry at transaction start.
If it is unclear whether your platform controls the specified good or service before transfer, pause posting and resolve the principal-versus-agent assessment first. For deeper detail, see ASC 606 for Platforms: How to Recognize Revenue When You're the Merchant of Record.
If you want a deeper dive, read Revenue-Based Financing for Payment Platforms: How to Use Future Transaction Volume as Collateral.
Turn the earned-event rule into a map that links each trigger to evidence, journal behavior, and cleanup behavior. If a reviewer cannot trace one fulfillment trigger to one journal pattern and one follow-up path, pre-billing revenue control is weak.
Start with the trigger event, then define the proof, posting date rule, and expected financial effect.
| Trigger event | Evidence source | Posting date | Debit account | Credit account | Expected balance sheet effect | Expected income statement effect |
|---|---|---|---|---|---|---|
| Service or delivery completed before invoice is issued | Fulfillment log, contract term, completion record | Earned date from fulfillment evidence | Current asset used for accrual (per chart-of-accounts policy) | Revenue | Current assets increase | Revenue increases |
| Invoice created for an item already accrued | Invoice record linked to original accrued item | Invoice date | Accounts receivable | Current asset previously used for accrual | Reclass from accrued current asset to billed receivable, no net asset change | No new revenue |
| Post-close review finds the original earned trigger was unsupported | Exception ticket, corrected fulfillment evidence, close-policy record | Correction date under close policy | Revenue | Current asset previously used for accrual | Current assets decrease | Revenue decreases |
Checkpoint: the first-row posting date should match earned evidence, not billing or cash timing. If contract support or fulfillment proof is missing, route to exceptions instead of posting.
For earned pre-billing events, map an adjusting entry that debits a current asset used for accrual and credits revenue. A documented pattern for earned-but-unreceived amounts is debit receivable and credit revenue; operationally, the key is recognizing the earned amount before cash and then reversing or reclassifying it correctly.
Define the follow-up paths in advance:
Without these paths, teams often double count by recognizing on accrual and then recognizing again at billing.
Use idempotency controls so retries do not create duplicate journals. Store a stable event reference and idempotency key with the posting request.
At close, reconcile GL balances with subledgers and work exceptions directly. A practical tie-out is a matched list of accrued events that later became invoices or approved reversals, with amounts and event IDs linked to the original accrual.
Build these exception lanes into the map:
For monthly sign-off, treat auto-approval as a controlled lane under your policy, not a default. If you use it, require prior close-cycle evidence that the trigger's evidence pack runs without exceptions.
You might also find this useful: 7 Revenue Leak Points in Subscription Platforms You Can Verify in 30 Days.
Start with classification: earned but unbilled amounts go to accrued revenue as a current asset, then move to A/R at invoicing without recognizing revenue again.
| Step | When it applies | Treatment |
|---|---|---|
| Pre-invoice accrual at period end | Service or delivery is complete before billing | Debit accrued revenue (current asset) and credit revenue |
| Reclass at invoicing | The right to consideration is unconditional after invoicing | Move the balance from accrued revenue to A/R and do not recognize revenue again |
| Prepayments | Cash is collected before delivery | Classify it as deferred (unearned) revenue in a liability account until the performance obligation is satisfied |
| Period cutoff | Invoices are issued after close | If the cutoff accrual was valid, the later invoice should reclass in normal flow; if the earned trigger was wrong, require explicit approval and a controlled correction entry |
Step 1: Post the pre-invoice accrual at period end. If service or delivery is complete before billing, post an adjusting entry tied to that earned event: debit accrued revenue (current asset) and credit revenue. Date it at the final moment of the accounting period (for example, December 31 or May 31) so recognition stays aligned to the earned period. Before posting, confirm the completion evidence and contract support are in place; if support is missing, hold the entry.
Step 2: Reclass at invoicing when the right is unconditional. After invoicing, when the right to consideration is unconditional, move the balance from accrued revenue to A/R. Use your documented reclass or reversal pattern so billing replaces the accrued asset instead of creating new revenue. Control for duplicates by matching the invoice to the original accrued item (for example, by event ID or contract reference).
Step 3: Keep prepayments in deferred or unearned revenue. If cash is collected before delivery, classify it as deferred (unearned) revenue in a liability account until the performance obligation is satisfied. Do not route prepayments through accrued revenue. A quick test: if delivery is complete, treat it as earned; if not, keep it in liabilities.
Step 4: Protect period cutoff. Invoices issued after close should not automatically rewrite prior-period revenue recognition. If the cutoff accrual was valid, the later invoice should reclass in normal flow; if later facts show the earned trigger was wrong, require explicit approval and a controlled correction entry. Track post-close invoices tied to prior accrued items and route revenue-timing changes to finance sign-off.
We covered this in detail in Recurring Billing for Marketplaces: How to Charge Buyers and Pay Sellers on the Same Cycle.
Your close stays cleaner when each earned amount sits in one balance-sheet state at period end: accrued, A/R, or deferred. If you cannot place an item in exactly one state, reconciliation noise and stale balances build quickly.
Step 1: Use one three-way reconciliation to show where each amount lives now. Treat this as a state table, not a report dump. Accrued revenue is a receivable-type asset, accounts receivable is billed but unpaid, and deferred revenue is a liability for cash collected before delivery.
| State at period end | Balance sheet home | What should exist as support | Main risk if it stays unresolved |
|---|---|---|---|
| Earned, not yet billed | Accrued revenue as a current asset | Earned-event evidence, contract term, invoice not yet issued | Stale accrued items roll forward without billing follow-up |
| Billed, not yet collected | Accounts receivable | Invoice, customer balance, A/R aging status | Collection risk rises as items age |
| Cash collected, not yet earned | Deferred or unearned revenue liability | Cash receipt, open delivery obligation | Revenue recognized too early |
Control check: each open line appears in one bucket only. If the same line appears in more than one state, fix the classification before close.
Step 2: Tie detail schedules to top-line balance sheet accounts every close. Run period-end tie-outs between subledger/detail activity and the related GL balances, including A/R aging-to-GL reconciliation as part of close. Apply the same discipline to accrued detail and deferred schedules so each support schedule ties to its control account for the same period.
Practical check: freeze detail schedules at cutoff and reconcile those snapshots to ledger balances for that period. Reconciling against live, changing data after close creates timing noise instead of surfacing real breaks.
Step 3: Age accrued items, not just receivables. Use aging views for accrued balances so old items trigger investigation instead of rolling forward indefinitely. Teams often use 1-30, 31-60, 61-90, and >90 day buckets for A/R; the same mindset helps surface stale accrued items.
If an accrued item carries forward, require an owner and a reason, such as delayed invoicing, missing completion evidence, or a trigger problem. Older unresolved items signal higher risk and need action.
Step 4: Apply scenario rules before changing revenue. If payment fails after a valid earned event, separate collection risk from recognition: keep the earned position if your policy supports it, and escalate collection or recovery handling. If you need an operating path, use Revenue Recovery Playbook for Platforms: From Failed Payment to Recovered Subscriber in 7 Steps.
If the earned trigger was wrong, post a reversal entry to cancel the prior adjusting entry and document the correction path. Use age as an investigation signal, not automatic proof that recognition was invalid.
This pairs well with Accounts Receivable Automation for Platforms to Collect from Enterprise Buyers at Scale.
Decide principal versus agent treatment before you automate posting logic. Under ASC 606, this is a fact-specific judgment, not an accounting policy election, and it drives whether revenue is presented gross or net on the income statement.
Document the two-step assessment first: identify the specified good or service, then assess whether your platform controls that specified good or service before transfer to the end customer. That control test is central to ASC 606, including ASC 606-10-55-37.
Your memo should clearly state the contract or product variant, the promised good or service, who delivers it, and when transfer occurs. If two reviewers cannot read the memo and reach the same posting result, the logic is not ready for automation.
Map the conclusion directly to journal behavior and presentation. Principal treatment means gross revenue presentation; agent treatment means net revenue presentation (for example, fee or commission).
Treat this as a reporting and ledger design decision, not a label exercise. If your model resembles Merchant of Record, still document why the control assessment supports the result, because the label alone does not settle the accounting outcome.
Do not force one global outcome across the whole arrangement. One contract can support principal treatment for some goods or services and agent treatment for others.
At the system level, map automated triggers to the memoed conclusion for each service line, not only to a single customer- or seller-level rule.
Reopen the assessment when approved contract modifications change scope, price, or both, or when fulfillment responsibilities shift between parties. Reassess again if operational transfer points change in practice.
Keep an active inventory of decision memos with effective dates and tie automation changes to that inventory. If contract terms change but posting logic does not, pause release and recheck the ASC 606 conclusion before the next posting cycle.
For a step-by-step walkthrough, see Platform Revenue Split Calculator for Modeling Marketplace Take Rates.
Treat timing errors as triage items: correct the entry, fix the trigger, and verify the control before close.
| Failure mode | Recovery step | Control check |
|---|---|---|
| Revenue was recognized before the performance obligation was satisfied. | Post a reversal entry (if the period is open), then trace the trigger to the missing earned-event evidence. | Each accrued posting ties to evidence of satisfaction under Step 5, not billing intent or cash expectation. |
| An invoice posted, but accrued revenue was not reclassed to A/R. | Reclass from accrued revenue to accounts receivable once invoiced, and clear exceptions promptly. | Open accrued balances are checked against invoice creation so billed amounts do not sit in both places. |
| Advance cash was treated as earned revenue. | Move it to deferred (unearned) revenue in the correct liability account until delivery occurs. | Release from deferred revenue is tied to delivery, not payment success alone. |
| Operating reality changed and posting logic no longer matches your role. | Reopen the principal-versus-agent assessment and refresh the policy memo before the next close. | Current posting rules match current responsibilities and contract flow. |
Copy and paste close checklist:
Need the full breakdown? Read How to Build a Float Management Strategy for Marketplace Platforms.
Want a quick next step for "accrued revenue platforms recognize revenue before buyers pay marketplace"? Browse Gruv tools.
The practical rule is simple: recognize revenue when the earning event is real, not when cash arrives, and keep the handoff from accrued revenue to A/R tight. In marketplaces, risk often sits in the handoff between fulfillment, invoicing, and close, not in the accounting rule itself.
Under accrual accounting, revenue follows delivery or completion of the relevant performance obligation. That means your first control is not payment status. It is evidence. For each trigger, keep a small but usable pack: the contract or fee terms, the fulfillment or service-completion record, the posting date, and invoice status. If proof of completion is weak, late, or contradictory, do not force the entry through close just because collection looks likely.
An adjusting journal entry is made before financial statements are issued so the books reflect accrual timing rather than cash timing. In practice, that means earned but not yet billed activity sits in accrued revenue first. The invoice is the boundary line: before it is sent, you have an accrued item; after it is sent, you should have A/R. A simple checkpoint works well: every new invoice should tie to an open accrued item or to a documented reason why no prior accrual existed. We recommend running that tie-out before your team closes the period, not after. If that tie-out is missing, it can lead to double counting, stale balances, or both.
Reconciliation is part of month-end close, and it should cover the balance-sheet accounts that tell the timing story, including A/R and accrued liabilities, along with related accrued or deferred revenue balances. Look for old accrued items that stayed open after invoicing, invoices that never reclassed, and entries posted from incomplete records. If payment fails after proper recognition, keep the revenue position and route it to collections review. If the earned trigger was wrong, reverse or correct the entry per policy and document why the original evidence failed.
A strong next move is to align finance, ops, and product on a documented trigger map and close checklist, then test that design through close scenarios before broadening automation. As the marketplace grows, complexity grows with it, so unresolved exceptions are not bookkeeping noise. They can signal that ownership, evidence, or cutoff discipline is slipping. If your team keeps explaining exceptions in meetings instead of in the ledger, the design is still too loose.
If you want to confirm what's supported for your specific country/program, Talk to Gruv.
Accrued revenue is income you have already earned even though you have not been paid yet. In a marketplace, that usually means the service or delivery event is complete, but buyer payment or invoicing happens later. Under accrual accounting, recognition timing follows earning, not cash receipt.
Recognize it when the good or service has been delivered under accrual accounting, because timing follows earning, not cash receipt. The key test is whether the revenue has been earned, not whether payment has arrived.
They are opposite timing states. Accrued revenue means you delivered first and will collect later. Deferred revenue, also called unearned revenue, means you collected first and still owe delivery, so it sits in a liability account until earned.
Before billing, accrued revenue represents earned but unbilled amounts. After invoicing, that open accrued balance typically moves to A/R because the amount is now billed.
Accrued revenue is the pre-bill earned state. A/R is the billed but uncollected state. At close, reconcile both so invoiced amounts are not still sitting in accrued revenue after an invoice is issued.
Yes. It can change whether revenue is presented on a gross or net basis. Under ASC 606, the principal versus agent assessment applies to arrangements with three or more parties. If useful, review this deeper guide on ASC 606 for Platforms: How to Recognize Revenue When You're the Merchant of Record.
There is no universal workflow in this grounding pack for open accrued items across multiple closes. Reassess whether the revenue is earned and whether invoicing has occurred, since invoicing is typically the transition point from accrued revenue to A/R.
Arun focuses on the systems layer: bookkeeping workflows, month-end checklists, and tool setups that prevent unpleasant surprises.
Includes 5 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
Failed payment recovery is an involuntary churn problem, not just a card-retry setting. On a marketplace platform, one failed renewal can still turn into a lost subscriber when product, engineering, and operations are not running the same recovery process.
If you run a Merchant of Record flow, cash movement is not your revenue policy. Under ASC 606, the hard part is that customer payment, processor settlement, and the point when revenue is actually earned can sit on different dates and in different records.
The hard part is not calculating a commission. It is proving you can pay the right person, in the right state, over the right rail, and explain every exception at month-end. If you cannot do that cleanly, your launch is not ready, even if the demo makes it look simple.