Cash Basis Revenue Recognition
When does $9,000 of rent become revenue? Most companies answer "when we invoice it" — that's accrual accounting, and it's REDA Financials' default. Smaller organizations (and some jurisdictions' tax regimes) answer "when the money actually arrives" — that's cash basis. REDA Financials supports both, per entity, with one setting: the entity's Accounting Basis. Day-to-day work looks identical; what changes is the accounting that posting and applying quietly produce.
Access you'll need. Any REDA Financials permission set can view the resulting records. Posting invoices and posting or applying receipts requires the Accounts Receivable v2 permission set (AR clerks & managers) or Accounting Admin v2 (system administrators). Setting an entity's Accounting Basis is an administrator task (Accounting Admin v2 or Accounting Controller v2).
The same invoice, two timelines
| Event | Accrual entity | Cash-basis entity |
|---|---|---|
| Invoice posts ($9,000 rent) | Revenue recognized now: DR Accounts Receivable / CR Rental Income | Revenue parked: DR Accounts Receivable / CR Deferred Revenue |
| Customer pays & receipt is applied | No revenue effect — just cash in, receivable cleared | Revenue recognized now: DR Deferred Revenue / CR Rental Income |
On cash basis, the income statement shows rent only when the rent is truly collected. The invoice still exists, still ages, still appears on statements — customers see no difference. Only the timing of revenue moves.
A worked half-payment, entry by entry
Follow $9,000 of rent through a cash-basis entity when the tenant pays half. Three documents, four sets of entries — all generated for you:
| Account | Debit | Credit |
|---|---|---|
| 1 — The invoice posts: the receivable is real, the revenue is parked | ||
| Accounts Receivable — Trade | $9,000.00 | |
| Deferred Revenue | $9,000.00 | |
| 2 — The $4,500 receipt posts: cash in, credit parked (same as any receipt) | ||
| Cash and Cash Equivalents | $4,500.00 | |
| Customer Deposits and Prepayments Received | $4,500.00 | |
| 3 — The application settles the invoice… | ||
| Customer Deposits and Prepayments Received | $4,500.00 | |
| Accounts Receivable — Trade | $4,500.00 | |
| 4 — …and recognition rides along with it: revenue becomes real | ||
| Deferred Revenue | $4,500.00 | |
| Rental Income — Offices | $4,500.00 | |
Steps 1–3 are the ordinary invoice-receipt-application flow you already know; step 4 is the cash-basis extra, created automatically by the application. The income statement now shows $4,500 of rent — exactly what was collected — and Deferred Revenue holds the $4,500 still waiting. When the second half arrives and is applied, step 4 repeats and Deferred Revenue empties.
How REDA Financials handles the details
- Recognition is proportional. A partial payment recognizes a proportional slice of each invoice line's revenue — a $4,500 payment on the $9,000 invoice recognizes half of every line, into each line's own revenue account.
- Tax never waits. Sales tax/VAT on the invoice posts to the tax payable account at invoice time even on cash basis — tax authorities don't wait for your collections. Recognition math therefore uses the revenue (pre-tax) portion of each application only.
- Cash-sale invoices don't defer. A Receipt-type (point-of-sale) invoice is paid the instant it posts, so its revenue is recognized immediately — deferral would be a meaningless detour.
- Credit memos don't defer either. A credit memo reverses revenue directly, whatever the basis.
- Un-applying un-recognizes. Remove an application (or void the receipt) and the recognized revenue returns to Deferred Revenue — the timeline stays truthful.
Two of those points deserve a closer look, because they're where cash-basis numbers surprise people:
The per-line split. Recognition doesn't lump everything into one revenue account — it slices the applied amount across the invoice's lines in proportion to each line's amount, crediting each line's own revenue account (any rounding remainder lands on the last line). An invoice with $6,000 of rent and $3,000 of service charges, half-paid, recognizes $3,000 of rental income and $1,500 of service revenue — your income statement stays as detailed as your billing.
The tax haircut. Because tax was already posted at invoice time, recognition works on the revenue-only portion of every application: recognized = applied × subtotal ÷ total. On a taxed invoice, a payment therefore recognizes slightly less revenue than the amount applied — the difference is the tax slice, which is already sitting in Tax Payable where it belongs. If you ever compare "cash collected" to "revenue recognized" and they don't match on taxed invoices, this is why, and it's correct.
Setting it up
Choose the basis on the entity
Entity setting Accounting Basis: Accrual or Cash. This is a books-wide decision made with your accountant — typically at entity creation, not switched casually mid-year.
Give a cash-basis entity a Deferred Revenue account
The parking spot for invoiced-but-uncollected revenue. Without it, posting an invoice is refused: "Entity … is on Cash basis but has no Default Deferred Revenue GL Account configured."
The rules that keep recognition clean
Cash basis adds only a handful of guards to the flows you already know — each is the exact message, with the remedy:
| The message | What to do |
|---|---|
| "Entity {0} is on Cash basis but has no Default Deferred Revenue GL Account configured." | Posting an invoice needs the parking account — a one-time entity setup task for your administrator. |
| "Default Deferred Revenue account is not configured for this entity." | The same gap caught at application time — recognition has nowhere to move revenue from. Same fix. |
| "Cannot create cash-basis recognition ATs: Sales Invoice "{0}" has no lines for proportional revenue recognition." | Recognition splits by line, so a line-less invoice can't recognize — a data-migration edge case; check how the invoice was imported. |
| "Application Date {0} falls on or before the AR book closure date ({1})." | Recognition lands in the application's period — closed books refuse it just like any application. |
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Journaling revenue recognition by hand | The application already recognized it — your journal doubles the revenue | Let applications drive recognition; journals are for what the subledger can't say |
| Reading the Deferred Revenue balance as an error | Someone "cleans it up" — and erases revenue that's legitimately waiting for collection | Deferred Revenue on cash basis should equal the revenue portion of open AR; reconcile, don't zero |
| Leaving receipts unapplied at period end | On cash basis, unapplied money is unrecognized revenue — the month's income statement understates collections that actually happened | Apply receipts before closing the period (the scheduled auto-apply batch makes this routine) |
| Switching an entity's Accounting Basis casually | Documents posted before and after the switch follow different rules — the year becomes a hybrid nobody can explain | Treat the basis as set-at-creation; a mid-life switch is an accountant-led project |
| Comparing revenue to gross collections on taxed invoices | They won't match — recognition is net of tax by design — and the "discrepancy" wastes an afternoon | Compare revenue to the subtotal portion of what was applied |
Reading your reports on cash basis
- Deferred Revenue balance = everything invoiced but not yet collected — it should always equal the revenue portion of your open AR.
- Rental Income (and other revenue accounts) = only what customers have actually paid.
- Watch collections, not billings, for your top line — the aging report tells you what revenue is still waiting to happen.
Where to go next
- Applying Receipts to Invoices — the action that triggers recognition.
- Posting a Sales Invoice — where the deferral begins.
- Closing the Books — period-end on either basis.
Frequently asked questions
That's an accounting-policy and often a legal/tax question — audited financials generally require accrual; some small-business tax regimes permit or prefer cash. Decide with your accountant; REDA Financials will faithfully implement either.
Not at all — same forms, same buttons, same applications. The difference is entirely in the accounting entries the system generates, which you can inspect on any document's Accounting Transactions list.
Half of each line's revenue, in that line's own revenue account (the tax portion of the invoice was already handled at posting). Pay the rest and the other half recognizes — the split is always proportional to the amounts applied.
Yes — the basis is per entity. A group can run its audited operating company on accrual and a small holding entity on cash, side by side.
No — it's the tax haircut. On a taxed invoice, recognition takes only the revenue portion of the application (applied × subtotal ÷ total), because the tax was already posted to Tax Payable when the invoice posted. The two amounts differ by exactly the tax slice.
Voiding the receipt mirrors its applications with negative ones, and each negative application de-recognizes: revenue moves back to Deferred Revenue. The invoice reopens, and the income statement no longer claims money you didn't keep. Un-applying by hand has the same effect — the recognition entries are removed with the application.
On the Accounting Transactions related to the cash receipt application that created them — settlement and recognition travel together. The invoice's own Accounting Transactions show the original deferral from posting.
Was this article helpful?