Deferred revenue for SaaS subscriptions with Stripe: simply explained with examples

pRAP stands for passive revenue accrual (deferred revenue). Behind it lies a simple principle: cash inflow and service delivery can occur at different times.

When a customer pays today for twelve months in advance, the money has already come in. But the service is only delivered in the coming months. That is exactly why the amount is often not fully recognized as revenue right away.

The legal basis is § 250 Abs. 2 HGB (German Commercial Code) and, for tax purposes, § 5 Abs. 5 EStG (German Income Tax Act): income received before the balance sheet date that represents revenue for a specific period afterwards is deferred as a liability. This applies to companies that prepare balance sheets. If you use cash-basis accounting (Einnahmenüberschussrechnung), you generally work on the cash principle – whether and how you need to defer should be clarified with your tax firm.

SaaS business models typically work with ongoing contract periods, monthly or annual plans, plan changes and renewals. This structure makes accrual questions especially relevant.

Stripe handles payment processing excellently, but not automatically the accounting valuation of the service period.

On 1 January, a customer pays 1.200 € via Stripe for an annual subscription, service period 01.01. to 31.12. The example is deliberately simplified and shown without VAT; how VAT on prepayments should be recorded is something to agree with your tax firm. Book fees and the payout as usual via the cash-in-transit account (Geldtransitkonto).

So in the month of payment, no revenue arises for the full amount; instead, a liability to the customer arises in the form of the pRAP. Each month, one twelfth is released: after three months, 300 € of revenue appears in the income statement and 900 € remains on the pRAP account. 0990 and 3900 are common standard accounts for deferred revenue – you decide on the specific account assignment with your tax firm. How Stripe fees on this payment are booked is shown in the guide Booking Stripe fees.

The goal of accrual is to allocate the revenue to the period in which the service is actually delivered.

On 1 July, the same customer switches to a larger plan for 2.400 € per year. Stripe prorates: a credit for the unused six months of the old plan (600 €) and a charge for six months of the new plan (1.200 €). The customer pays the difference of 600 €.

Revenue for the year totals 1.800 €, which corresponds exactly to the 1.200 € plus 600 € paid. The key point is that from July onwards, the new monthly amount of 200 € is released. A downgrade works the other way round: the credit reduces the pRAP and the monthly release amount decreases.

Variant: the customer cancels as of 31 March and receives a pro-rata refund for the remaining nine months. After three releases, 900 € remains on the pRAP account – and exactly this amount is refunded.

Revenue remains at 300 € for the three months actually delivered, and no further releases are made. If the subscription is cancelled at the end of the term without a refund, the release continues unchanged. If the refund differs from the remaining pRAP amount, for example as a goodwill gesture, the difference must be treated separately – agree the approach with your tax firm.

On the balance sheet date, the liabilities side shows the portion of all prepayments whose service period falls in the new year. An accrual schedule per invoice serves as evidence. Its total must match the balance of the pRAP account:

The 2.650 € will be released in the following year. If the monthly releases run cleanly, no special booking is needed at year-end – you just reconcile the schedule with the account balance.

Monthly subscriptions are usually simpler because payment and service period are closer together. Even so, special cases are possible here too, for example when an upgrade, downgrade or a pro-rata credit occurs mid-month. So the complexity decreases, but it does not disappear completely.

A typical case is the turn of the year: a monthly subscription from 15.12. to 14.01. spans two financial years. Whether such amounts are deferred also depends on materiality – again, a question for your tax firm.

For a robust pRAP logic, payment data alone is not enough. The following are typically relevant:

Stripe provides the most important information at invoice level: every line item of a subscription carries a service period with a start and end (in the API as period start/end). Prorated line items from upgrades and downgrades also have their own period. How subscription invoices get into DATEV overall is described in the guide Stripe Billing to DATEV.

Other special cases with Stripe subscriptions

In practice, pRAP is not made complicated by the standard case but by special cases:

• Annual subscription with a later upgrade
• Downgrade in the middle of the contract period
• Partial refund
• Contract renewal before the end of the term
• Cancellation shortly after payment

It is precisely at these points that a clean data logic is needed so that finance teams do not have to improvise outside the standard process.

• The entire annual amount is recognized as revenue immediately.
• Refunds are not included in the accrual logic.
• Contract periods are not cleanly linked to payments.
• Plan changes are solved manually outside the standard process.
• Tax advisors only receive raw data instead of a prepared structure.

finHero reads the service periods from your Stripe invoices and creates the deferral from them – without an Excel list alongside your accounting. The connection runs via the finHero app in the Stripe App Marketplace: a few clicks, no code, read-only access only.

• pRAP for annual subscriptions is created automatically and released monthly.
• Upgrades and downgrades are automatically corrected in the deferral.
• Bookings using SKR03, SKR04 or your own accounts in the DATEV booking batch.
• Invoices and credit notes as PDF receipts, linked via the transaction ID.
• Exports also possible retroactively, for example for a financial year already in progress.

The complete process from export to import is described in the guide Importing Stripe into DATEV.