Three routes lead from a payment provider or shop into the DATEV world, and what separates them is the level of detail they deliver. The first is DATEV's own data services: the payment data service for PayPal, the payment data service for Amazon, and the newer payment provider data service, which DATEV says covers Amazon Pay, eBay, Klarna, Mollie, Shopify and Stripe. The second runs through intermediary services that turn raw data into ready-made posting proposals. The third uses on-board tools: download the report, import it, or match it by hand. The difficulty is not technical. A payment provider transfers you a lump-sum payout that has already been reduced by fees, refunds and chargebacks, and depending on the provider that payout lands every few days, not with every order. Post that amount as revenue and you have neither the gross turnover nor the fee in your books. So the deciding question is the same on all three routes: do gross amount, fee and payout stay separate, or does a single number arrive at the end?
What interests me here is less the pipe than what comes out of it. I do not sell through a shop myself, but I know the matching problem from my own bookkeeping: a collective statement with many line items, individual receipts next to it, and someone in the middle bringing the two together line by line. Exactly that preparation runs automated here, while posting and sign-off stay with people. What that setup looks like is on Hiring AI employees and in AI Agent for Bookkeeping and Inbox. The fundamentals of a DATEV connection, meaning Unternehmen online, the data services and the access media, are in DATEV Integration: The Basics; this post only covers the payment provider in front of it. The other end of the chain, from order to invoice, is covered in Automating Marketplace Invoices. And: this is not tax advice. Which accounts and which route suit your books is something you decide with your tax adviser.
Why the payout is not your revenue
The payment providers say so themselves, you just have to read their reporting documentation. Stripe describes the payout reconciliation report as a way to "reconcile payouts received in your bank account with the batches of payments and other related transactions". The columns of that report are called gross, fee and net: gross amount of the transaction, fees paid, net amount. Three numbers per transaction, and only the third one arrives through your bank.
Shopify is built the same way. A payout has a net field, "the total amount and currency of the payout", and next to it a summary that breaks fees and gross amounts down by transaction type: chargesGross and chargesFee for payments, refundsFeeGross and refundsFee for refunds, adjustmentsGross and adjustmentsFee for adjustments including disputes, plus separate fields for reserved funds and for retried payouts. PayPal's Balance Reconciliation Report carries a "Gross Transaction Amount", which PayPal defines as the "total amount of the transaction before deducting fees", and a "Net Transaction Amount", meaning gross minus total net fees minus partner commission.
A constructed calculation, not a real statement: ten orders of 100 euros each, one refund of 100 euros, fees of 30 euros in total. A credit of 870 euros shows up in your bank account. Post that as revenue and you have hidden 1,000 euros of gross turnover, a refund and 30 euros of business expense inside a single figure. It will surface at the latest when the sum of the invoices you wrote refuses to match the sum of your bank credits. The bridge here is deliberately simplified: reserves, withheld tax and currency conversion can move the bank amount further.
Three effects make the matching harder still, all three visible in the report columns.
- Timing. Stripe keeps two date fields apart:
available_on, when the funds become available in your Stripe balance, and automatic_payout_effective_at, when the payout is expected to arrive in your bank account. A sale from the end of the month can therefore sit in next month's payout. Stripe covers that with an "ending balance reconciliation" section in the same report, holding the transactions that had not been paid out by the cut-off date.
- Currency. Besides
currency, the Stripe report knows customer_facing_amount and customer_facing_currency, that is "the amount as seen by the customer" when the payment was made in a currency other than your account currency. Two amounts, two currencies, one transaction.
- Refunds and chargebacks. They run with a delay and in their own categories: in Shopify as separate field pairs in the payout summary, in Stripe as a separate reporting category. Either one can shrink a payout without you having cancelled anything in that period.
Route 1: DATEV's built-in data services
DATEV runs its own cloud services for payment providers, alongside the bank data service, the posting data service and the invoice data service; three of them matter for online trade. All prices below come from the DATEV price list for companies, as of 08/2026, in euros and excluding VAT.
DATEV describes the two payment data services as collecting, providing and storing the transactions in the DATEV cloud. For PayPal, the product page promises daily provision of transactions and processing "analogous to electronic bank posting"; DATEV states that PayPal transactions are archived in the cloud for 14 years. For Amazon, the transactions only arrive "as soon as a payout from Amazon has been made (usually every 14 days)". In both cases the account is created in the accounting program under master data and payment providers, and that is precisely what rules out many small businesses: the services require a DATEV accounting program, one your tax firm typically works in, not you.
Two points in the price list deserve a look. According to DATEV, the base price for both payment data services applies regardless of any data transfer, once transactions have been provided for the first time. And the tiers rise faster than the entry price suggests: up to 1,000 transactions 2.62 euros, up to 5,000 transactions 10.50 euros, up to 10,000 transactions 15.75 euros. Plus a date worth knowing before you decide: for the Amazon payment data service, DATEV's product page names 15 August 2027 as the date on which further development, maintenance and support will end, and it names no successor product.
The payment provider data service is the newer and broader option. DATEV describes it as collecting payment data "in an online application", automatically assigning it to the matching invoice postings and providing it as posting proposals, with rule-based automation and reconciliation through a "settlement reference" field. The interesting part: the service does not treat the payment as a bank transaction, it tries to attach it to the invoice it belongs to. The tier starts at 10.00 euros per month and already sits at 76.00 euros at 5,000 transactions. It is set up inside the accounting program under company data and online applications; DATEV names tax firms with e-commerce clients and self-posting clients as the target group.
Route 2: Intermediary services, when the software will not play along
Anyone working in a cloud tool rather than a DATEV accounting program runs into a limit the vendors name themselves. Lexware writes for Lexware Office that Stripe, eBay, Etsy, Mollie and Amazon cannot be connected directly: either you post the payouts manually and assign the matching receipts, or you use a partner integration. Lexware names Billbee for that and recommends services like PayJoe or Miracle Sync from roughly 50 to 100 receipts per payout onwards. PayPal is one of the few accounts there with its own interface and automatic retrieval, and for shops there is an ePages and a Shopify integration. Which routes this one tool offers in detail is in Lexoffice Integration: The Main Routes; which programs else are worth a look is in Accounting Software for Small Businesses.
The test question is the same as above: one record per order with gross amount and fee, or the payout handed over as a single transaction? In the second case the manual work is not gone, just moved. Ask as well about error logs, protection against double postings, how far the history reaches back at the start, and what happens to your data if you cancel.
Route 3: Download the report, import the file
The third route sounds old-fashioned and is the fastest one for small volumes, because all three providers hand out the raw data. Stripe offers a CSV download per section in the dashboard, either as a summary or as "itemized", meaning "the full list of individual transactions summarized in the dashboard", and allows your own metadata to speed up matching; Stripe says the data is usually available from 12:00 the following day. PayPal generates the Balance Reconciliation Report daily and places it as a CSV on an SFTP server. Shopify supplies the payout summary with the gross and fee fields listed above.
On the DATEV side, the counterpart is the posting batch in DATEV format, a file your tax firm imports without you needing a data service of your own; how that file is built is in the fundamentals post DATEV Integration: The Basics. In between sit three stages: the raw report with the provider's own column names, from it prepared posting data with account, tax key and receipt reference, and from that the import file in the agreed format. You cut that pattern once and test it on a trial period; no data service has to be set up and paid for monthly. If you get stuck on the cut, bring your column header into the community.
This applies to all three routes: the Stripe report columns optionally contain customer name, email address and shipping address, so you are handing customer data to another system. For bookkeeping, amount, fee, date and reference are usually enough; export only those columns, and clarify beforehand who the recipient is and what your contract with them covers. What you give to whom is sorted out in AI and Privacy: What the AI Gets to See.
The checklist before you decide
Five questions sort the three routes.
- Do gross and fee arrive separately, or only the net amount? If only net arrives, the fee is buried in the revenue and the business expense is missing. How you set accounts, VAT, exchange rate and the date of supply is something you settle with your tax adviser.
- Is there a bracket per payout? A payout ID on every record turns a bank credit into a group you can check.
- How are refunds and chargebacks handled? As separate records with their own date, or netted off and invisible?
- Are both currencies there? For payments in foreign currency you need the amount the customer saw and the amount in your account currency.
- Which date counts? Payment date, availability date and payout date are three different things, and across a month boundary they drift apart.
What an AI employee does at this point
A connection transports. It does not decide whether a line item matches a receipt. That is exactly where Peter, my AI employee for receipts and bookkeeping, sits. He does not work on an interface but in my accounting interface in the browser: he reviews the newly arrived receipts, assigns the correct receipt type to each one, matches the credit card statement against them line by line and reports what does not fit. He follows a written process description; what is not in it, he does not do.
That is the same reconciliation as with a lump-sum payout, only with a different counterpart. Three rules are hard-wired in him. He clicks nothing on suspicion: every state-changing action is covered by a step in an approved process. Amounts, dates and receipt numbers always come from the screen, never from memory; if an amount deviates, he reports the item as open instead of making it fit. And he does not post: sign-off stays with me and my tax adviser. In one run in September his own control calculation came out at zero discrepancies, and one single item stayed open on purpose because the amount on the receipt did not match the statement.
How that browser work runs technically is in Claude in Chrome: How to Use the Extension; what today's tools can do on their own when reading and coding receipts is sorted out in AI Bookkeeping: What Actually Works Today.
Frequently asked questions
Can I connect Stripe to DATEV directly?
Through the DATEV payment provider data service, yes. DATEV lists Amazon Pay, eBay, Klarna, Mollie, Shopify and Stripe there and describes the service as an extension of the existing interfaces for PayPal and Amazon. According to the price list the tier starts at 10.00 euros per month for up to 500 transactions, excluding VAT, as of 08/2026.
What does the PayPal connection to DATEV cost?
The payment data service for PayPal starts at 1.36 euros per month for up to 500 transactions according to the DATEV price list for companies, excluding VAT, as of 08/2026. The tier rises with transaction volume: 2.62 euros at up to 1,000 transactions, 10.50 euros at up to 5,000.
Is it enough to post the payout as revenue?
That leaves two numbers out. The payout is the amount after fees have been deducted and refunds netted off; that is why Stripe, Shopify and PayPal all keep gross, fee and net as separate fields in their reports. How you represent those amounts in your books belongs in the conversation with your tax adviser.
Do I need a DATEV program for the data services?
For the two payment data services DATEV names an accounting program as the requirement, meaning DATEV Kanzlei-Rechnungswesen, DATEV Mittelstand Faktura mit Rechnungswesen or Rechnungswesen kommunal. The payment provider data service is likewise created inside the accounting program. Anyone not working in those goes through an intermediary service or through an export file.
What is happening to the Amazon payment data service?
DATEV notes on the product page that further development, maintenance and support for this product will end on 15 August 2027, and names no successor product there. The payment provider data service lists Amazon Pay, the checkout service for third-party shops, so it is not automatically the route for payouts from your Amazon account. Ask DATEV or your tax firm about that route early, because ordering and setup sit there.
How to take the next step
Start with a single payout. Take the last bank credit from your payment provider, pull the matching report as a CSV and check by hand whether gross total minus fees minus refunds gives exactly that amount. That answers three questions at once: how many items pile up per payout, which special cases your business actually produces, and whether the volumes justify a paid data service. With those numbers in hand the conversation with your tax firm is short.
If you then find that the manual work is not the problem but the exceptions are, the question becomes who checks them. How I hand that checking work to an AI employee without handing over control is what I show step by step in my community Claude Practitioners.
