Deferred revenue in German accounting (pRAP): definition, bookings and an example

What is a deferred revenue item (pRAP)?

A deferred revenue item (passiver Rechnungsabgrenzungsposten, pRAP) makes sure that a receipt becomes revenue in the financial year in which you provide the service, not in the one in which the money arrives. The German Commercial Code puts it this way: "Receipts before the balance sheet date are to be shown as deferred items on the liabilities side to the extent that they represent revenue for a specific period after that date" (§ 250(2) HGB, German). For the tax balance sheet, the same idea appears almost word for word in § 5(5) sentence 1 no. 2 EStG (German Income Tax Act, German).

This gives three conditions, all of which must be met:

1. Receipt before the balance sheet date. The money has arrived or the receivable has been booked.
2. Revenue after the balance sheet date. Part of the service is still outstanding at the balance sheet date.
3. A specific period. The service period is fixed by calendar or objectively calculable, for example twelve months from activation. The BFH (Germany's Federal Fiscal Court) confirmed this again for time-related services in 2023 (IV R 22/20, German).

Without that time element, it is not a pRAP. If a customer pays in December for a coffee machine that only ships in January, that is a down payment received for a single delivery. Vouchers are another case of their own: when they are sold, it is not yet clear when and for what they will be redeemed. They are booked as a liability; more on that under vouchers.

In accounting language the pRAP is also called a transitory item, because the payment comes before the balance sheet date and the revenue after it. The reverse case (revenue in the old year, payment only in the new one) is called anticipatory. It is not a deferral within the meaning of § 250 HGB and is handled through other receivables.

Who has to create deferred revenue?

Only businesses that prepare a balance sheet have to defer. That includes all corporations, so every GmbH and UG (German limited companies), regardless of revenue and size: the GmbH counts as a commercial company (§ 13(3) GmbHG, German), and the bookkeeping obligations of merchants apply to it (§ 6(1), § 238(1) HGB, both German). Sole traders only have to prepare a balance sheet above the thresholds of § 241a HGB (German): more than €800,000 in revenue or more than €80,000 in annual profit on two consecutive balance sheet dates.

If you determine your profit using cash-basis accounting (Einnahmen-Überschuss-Rechnung, EÜR), there is no pRAP. The cash principle of § 11 EStG (German) applies: an annual payment received in October is a receipt in October.

Booking a pRAP: creating and releasing it

Every pRAP needs two bookings. When creating it, the net share not yet earned moves from the revenue account to the pRAP account. When releasing it, it flows back into revenue, in the period in which you provide the service. In DATEV's standard charts of accounts (DATEV is the accounting software most German tax advisors use), the account is called "Passive Rechnungsabgrenzung" and has the number 0990 in SKR03 and 3900 in SKR04. German booking notation reads "X an Y", meaning debit X, credit Y; below we write it as Dr/Cr.

There are two common ways to time the creation:

• Immediately with the invoice. You defer everything that belongs to later months in the invoice month already, then release the pRAP month by month. Your BWA (the monthly management report your tax advisor produces from DATEV) then shows the revenue you actually earned in each month.
• Only at the balance sheet date. You first book the full invoice as revenue and defer once at year-end: revenue to pRAP for the share that belongs to the new year. In the new year the release follows, monthly or in one amount.

At the balance sheet date, both approaches put the same pRAP on the balance sheet. During the year they differ: with the second approach, the BWA shows a revenue spike in the month of sale that does not exist economically. If you need monthly figures for planning, your bank or investors, use the first approach.

VAT runs independently of this. On a prepayment, it arises at the end of the VAT reporting period in which the money arrives (§ 13(1) no. 1(a) sentence 4 UStG, German), and for the full amount. That is why you always create the pRAP net.

Worked example: a SaaS annual plan for €1,200

On July 1, 2026, a customer books an annual plan for your software at €1,200 net (€1,428 gross) and pays immediately. The service runs from July 1, 2026 to June 30, 2027, and your financial year is the calendar year. €100 falls on each month. All figures are an example calculation.

Month by month, the year looks like this (created immediately with the invoice, amounts in euros):

Nothing special happens in the books at year-end. The pRAP balance of €600 appears in the closing balance sheet for 2026 and is carried forward as the opening balance into the new year. If your financial year differs from the calendar year, its last day is the balance sheet date.

Spread daily or monthly?

If the term starts on the first of a month, both methods give the same result. It is different when the plan starts mid-month. Same example, but the customer books on October 15, 2026, and the term ends on October 14, 2027. That is 365 days, so about €3.29 per day.

The last month absorbs the one-cent rounding difference so that the total comes to exactly €1,200. With a simplified two and a half service months up to New Year's Eve, you would get €250 revenue and €950 pRAP, a difference of €6.44.

Which method fits? Plans measured in days (such as 30 days) are deferred daily. For monthly and annual plans, spreading evenly by month is common. A flat monthly approximation is acceptable as long as the difference stays immaterial. Agree on the method once with your tax advisor and stick with it.

The €800 limit and the materiality principle

Since the Annual Tax Act 2022, § 5(5) sentence 2 EStG (German) contains a tax option: "A deferral need not be recognized if the respective expenditure or receipt within the meaning of sentence 1 does not exceed the amount in § 6(2) sentence 1". That amount is currently €800 (§ 6(2) sentence 1 EStG, German). The rule applies for the first time to financial years ending after December 31, 2021 (§ 52 EStG, German).

In practice, three points decide:

1. Uniform. The option must be exercised uniformly for all expenditures and receipts, so for prepaid expenses and deferred revenue at the same time (§ 5(5) sentence 2, second half-sentence EStG). You cannot skip the pRAP for 300 small annual subscriptions and still create an aRAP for your own insurance.
2. Per receipt. What counts is the respective receipt, so usually a single payment from one customer. Comparing it with €800 net is common practice, derived from the reference to § 6(2) EStG. The highest court has not yet settled this for deferrals.
3. Tax balance sheet only. The option is in the EStG. The HGB has no amount limit; § 250(2) HGB says items "are to be shown". Whether immaterial items may be left out of the commercial balance sheet under the materiality principle is disputed in the literature. How you handle it under commercial law is up to your tax advisor.

Before the change in the law, the BFH had explicitly rejected materiality as a justification, and even small amounts had to be deferred (judgment of March 16, 2021, X R 34/19, German). For SaaS providers with many low-priced annual subscriptions, the limit is therefore a real relief. If you sell plans above €800 net, you keep deferring those.

Upgrade, downgrade and cancellation during a subscription

In the subscription business, a contract rarely stays the way it started. The principle is always the same: the pRAP only holds the amount attributable to a service still outstanding. If the service or the price changes, you adjust the pRAP. The table describes the usual treatment; if your contract terms differ, check with your tax advisor.

A payment default or a chargeback does not change the service period. It affects the receivable, not how the revenue is spread.

Common mistakes with deferred revenue

• Deferring gross: VAT does not belong in the pRAP, because it arose in full with the prepayment.
• Deferring the whole payment, even though the share up to the balance sheet date has already been earned and belongs in the old year's revenue.
• Deferring although you use cash-basis accounting (EÜR). Without a balance sheet there is no pRAP.
• Booking a down payment as a pRAP. A prepayment for a single delivery is a down payment received.
• Using the option only halfway. The €800 limit applies uniformly to aRAP and pRAP and for the whole financial year.
• No service period on the invoice. Without a start and end of the service, the deferral is hard to prove. How the period gets onto the invoice is explained under date of supply.
• Booking prior-year months in the current year. If you only issue an invoice in the new year for a period that began in the old one, the past months belong in the old financial year. If that year is already closed, a balance sheet correction is needed.

Prepaid expenses (aRAP) as the counterpart

Prepaid expenses (aktive Rechnungsabgrenzung, aRAP) are the mirror image. Under § 250(1) HGB (German), "expenditures before the balance sheet date are to be shown on the assets side to the extent that they represent expense for a specific period after that date". Typical examples are insurance premiums, vehicle tax, prepaid rent and annual licenses for software you use yourself.

An example: on October 1 you pay €1,200 for business liability insurance until September 30 of the following year. €300 is an expense in the old year, €900 belongs to the new one and appears on the balance sheet as an aRAP at the balance sheet date.

As a rule of thumb: aRAP means spend now, expense later. pRAP means receive now, revenue later.

In a SaaS business or a shop, it is mostly the pRAP that comes up all the time, because it arises with every prepaid sale. Your tax advisor usually creates the aRAP once in the annual financial statements from your own cost documents.

Subscription software and online courses raise questions of their own: when is course access really a service over time, how do you separate setup from subscription, and what should software document for it? The page deferred revenue for SaaS and online courses answers them.

How Rechnungskit books deferred revenue

Rechnungskit writes every subscription document as an e-invoice with a service period, whether it comes from Stripe Billing, from your own subscription billing or through the API. What Stripe provides and what it does not is shown in Stripe and DATEV. If you prepare a balance sheet, the DATEV export adds the deferred revenue bookings:

• Creation in the invoice month. The net share attributable to later months moves from the revenue account to the pRAP account.
• Release in every following month. At each month-end, the export books that month's share from the pRAP account back to the revenue account, also across the year-end.
• Net and accurate to the cent. The bookings carry no tax key, because the VAT arose with the invoice. Creation and releases add up to exactly the deferred amount.
• Choice of method. In the DATEV settings you choose monthly, daily on a 30/360 basis, or daily by calendar days. With "monthly", every calendar month of the period gets the same share; if an annual plan starts mid-month, the amount is therefore spread over 13 calendar months. For such plans, daily is the more accurate choice.
• Corrections mirror the original. A cancellation invoice (Storno) or a credit note (Gutschrift) takes over the service period of the original invoice, and its deferral is booked with the opposite sign.
• Option per financial year. You decide whether all deferrals are recognized or the uniform option up to €800 net applies, and confirm that it is exercised uniformly for aRAP and pRAP. Finalizing an export locks this decision for the financial year.

Two settings are required: you have chosen balance sheet as your method of profit determination, and the pRAP account is set (prefilled with 0990 or 3900, changeable to a sub-account of your tax advisor). With cash-basis accounting (EÜR), Rechnungskit deliberately books no deferral. Your tax advisor still creates the aRAP for your own costs, because Rechnungskit only sees your outgoing invoices.

How invoices for software subscriptions work overall is shown in e-invoicing for SaaS.