Stripe accounting in Germany: what needs to land in DATEV?The overview for companies and tax firms

In many companies, Stripe accounting starts from a false premise: that everything visible in Stripe is automatically usable for accounting purposes too. That is exactly not the case. DATEV needs not just data, but a structure that makes sense both fiscally and operationally. Without this structure you get unclear payouts, missing receipt references, inconsistent fee bookings and unnecessary follow-up questions at the monthly close.

On top of that, Stripe pays out net. Between the customer's payment and the money arriving in the bank account lie fees, refunds, possibly chargebacks and a time lag. Stripe accounting must make these steps visible individually instead of booking only the payout amount.

From an accounting perspective, Stripe data can be reduced to a few layers. Each layer is represented as its own referenceable booking.

Payments and revenue

The first building block is the individual customer payments. They form the basis of the revenue logic. What matters is that not only total amounts are exported, but that the individual movements remain cleanly referenceable. So what's relevant in DATEV is not just “how much was paid out”, but above all “which revenue lies behind it”.

Stripe fees

Fees are one of the most common weak points in manual processes. They are often carried along somewhere, but not exported in such a structured way that they can be processed at the monthly close without additional logic. In DATEV, fees should appear as clearly identifiable, separately traceable components. Anyone looking only at the net amount of a payout quickly loses sight of this level.

Refunds, cancellations and chargebacks

Refunds, partial refunds and other corrections change not only the payment flow but the entire revenue picture. That's why, in a robust export logic, they must be clearly linked to the original transactions. As soon as these cases are added manually “afterwards”, the risk of error rises sharply.

Chargebacks (disputes) behave similarly: the amount and the associated dispute fee are deducted from the Stripe balance. If you win the dispute, the amount is credited back – this too is a separate movement that has to be booked.

The layers at a glance

Payouts are important, but not sufficient. They help with reconciliation against the bank account, but must not be the sole accounting basis. A clean process links individual transactions with the later payouts. Only this makes it traceable how a payout amount is composed.

Receipts are not optional for efficient accounting. Invoices, credit notes or receipt links must be available in such a way that individual bookings can still be traced later on. A technical data export without receipt references may suffice at first, but in practice it leads to follow-up questions, manual rework and uncertainty in special cases.

Which receipts you need specifically depends on your business model. Typically, these documents are part of Stripe accounting:

The link is what matters: every booking should be matchable to the right receipt via a reference such as the transaction ID. A receipt list connecting booking and document saves your tax firm many follow-up questions.

Stripe itself makes no tax classification – the payment only says that money has moved. What matters for accounting is who the customer is and where they are based. This determines which revenue account a sale belongs to and which tax rate or tax key applies.

For clean Stripe accounting you therefore need, per payment, at least the customer's country, the VAT ID where applicable and the tax amount shown. This information should come from the invoice or customer data – not be estimated after the fact.

One principle has proven itself in practice: the Stripe balance is treated like an intermediate account, usually via the cash-in-transit account (Geldtransitkonto, e.g. 1360 in SKR03 or 1460 in SKR04). Payments flow in, fees and refunds flow out, and the payout to the bank account balances it.

Calculation: 119,00 + 59,50 − 3,00 − 29,75 = €145,75 payout. The cash-in-transit account is then balanced.

If everything adds up, the cash-in-transit account is at zero after each payout, or at the amount still held at Stripe. How to assign the individual bookings to accounts and resolve special cases is shown in the detailed guide Booking Stripe in your accounting.

For SaaS companies, another level comes into play: recurring revenue. Especially with annual plans or prepayments, it's often not enough to simply treat the payment as full revenue in the month it's received. That's why DATEV needs to receive not just the payment and the receipt, but also the basis for clean revenue recognition, where that is required.

A typical example is an annual plan paid in full in January but covering twelve months of service. How this is booked in practice is explained in the article on deferred income (pRAP) for SaaS subscriptions.

Stripe accounting works best as a fixed monthly process. A proven sequence:

1. 1Close the periodCapture all of the month's payments, fees, refunds and payouts from Stripe – completely, not just the payouts.
2. 2Match receiptsMatch invoices, credit notes and the fee statement to the bookings, ideally via the transaction ID.
3. 3Classify for taxSeparate sales into domestic, EU and non-EU and book them to the revenue accounts agreed with your tax firm.
4. 4DeferFor annual or advance payments, defer the portion for later months and release it monthly.
5. 5ReconcileReconcile the cash-in-transit account against the Stripe balance report and bank statements. Clear up open differences before handing over.
6. 6Hand overHand the booking batch and receipts to your tax firm or have them imported into DATEV.

Among other things, the GoBD (German principles for proper electronic bookkeeping) require bookings to be complete, correct, timely and traceable, and records to be stored in an unalterable form. For Stripe this means: the path from the individual payment via the booking to the receipt must be traceable at any time.

Helpful are a process documentation (Verfahrensdokumentation) for the sub-process “payment service provider → financial accounting”, reproducible exports and data access in machine-readable form. Details in the article GoBD-compliant export.

With only a few payments a month, a manual approach is possible. With growing volume, subscriptions and international customers, however, the effort rises quickly.