In short A Billbee to DATEV integration turns every invoice and credit note Billbee generates across Amazon, eBay, and your own shop into a coded Buchungsstapel your Steuerberater imports directly. Each document books against the right collective debtor per sales channel, split by VAT rate with the correct tax key for domestic, OSS, and third-country, and settled through a per-channel clearing account. Not a monthly CSV download but a daily, idempotent pipeline keyed on Billbee invoice numbers, so nothing is booked twice.
What a Billbee to DATEV integration actually does
Billbee is where a multichannel seller’s commercial truth lives. It pulls orders from Amazon, eBay, Kaufland, OTTO, Etsy, and your own Shopify, Shopware, or WooCommerce shop, normalises them into one order model, assigns an invoice number from your own range, and generates the invoice PDF. That is a genuinely good starting point - far better than exporting each marketplace separately.
What Billbee does not do is accounting. It has no chart of accounts, no tax keys, no notion of a debtor account, and no view of what the marketplace actually paid out after commission. DATEV, and the Steuerberater working inside it, needs exactly those things: an account, a Steuerschlüssel, a posting date, a Belegfeld, and a clearing side that reconciles against the bank.
A Billbee to DATEV integration closes that gap on a schedule. It reads each finalised document out of Billbee, applies the coding rules agreed once with your Kanzlei, and hands DATEV a Buchungsstapel that imports without anyone opening a spreadsheet.
What data moves
| Billbee object / event | Becomes in DATEV | Notes |
|---|
| Invoice created on an order | Revenue booking against the channel’s debtor | Billbee invoice number goes into Belegfeld1 |
| Order items with tax rate | Revenue lines split per VAT rate and tax key | Domestic 19% / 7%, OSS destination rate, reverse charge, third-country export |
| Shipping cost and surcharges | Separate booking lines | Taxed at the rate of the shipped goods, own revenue account |
| Credit note / return (Retoure) | Reversing booking | Same accounts and tax keys as the original, dated to the credit note |
| Payment method and paid date | Clearing account per channel or PSP | PayPal, Klarna, Amazon Payments, Mollie, bank transfer each kept apart |
| Buyer with VAT ID (B2B) | Debitorenstammsatz | Only where individual debtor accounts are wanted |
| Invoice PDF generated by Billbee | Beleg in DATEV Unternehmen online | Linked to the booking through the document number |
| Marketplace settlement report | Fee expense plus payout reconciliation | Not from Billbee - a second source, if fees are in scope |
The accounts, tax keys, debtor ranges, and clearing accounts are agreed once with your tax advisor and encoded in the pipeline. After that nobody maps them again by hand.
The details that break naive exports
- The invoice, not the order, is the accounting document. Billbee orders move through states, get cancelled, get partially returned. Booking on order creation puts revenue in the ledger that may never exist. The trigger has to be the invoice, with the Billbee invoice number as the stable idempotency key.
- One document, several tax treatments. A single Billbee invoice can hold a 19% item, a 7% book, and shipping. Marketplace orders shipped into other EU countries need the destination rate under OSS, EU B2B customers with a valid VAT ID need reverse charge, and a Swiss delivery is an export. That is four different tax keys inside one order stream.
- Gross-to-net rounding. Billbee stores gross prices per order item. Recomputing net line by line and summing can land a cent away from the invoice total. The booking has to tie to the document total the customer received, not to a recalculation.
- Debtors and channels. An Amazon order carries a pseudonymised buyer address and no usable debtor identity. Almost every setup books marketplace sales against a Sammeldebitor per channel and keeps individual debtors for B2B and direct-shop business.
- The payout is not the revenue. Amazon and eBay settle in batches, net of commission, days later, spanning hundreds of documents. Without a per-channel clearing account, the bank booking reconciles to nothing.
- API throughput. The Billbee API is deliberately rate-limited to a low number of requests per second, with tighter caps on some endpoints. A naive full backfill of a year of invoices either takes hours or gets throttled halfway through. Delta sync on the modification timestamp, correct paging, and resumable runs are not optional.
- UTC versus local period boundaries. Billbee timestamps are UTC. An order placed at 00:30 CEST on the first of the month is dated to the previous month if you filter naively - which is exactly the kind of drift a Steuerberater notices after the Voranmeldung is filed.
- Belegfeld constraints. DATEV restricts the characters and length allowed in the document field. Marketplace order references and some invoice prefixes do not survive an unfiltered copy, and the batch is rejected on import.
How we build and run it
We build it as a pipeline, not a scheduled script. Billbee invoices and credit notes are pulled incrementally by modification date, validated against a schema, mapped into your agreed DATEV coding, aggregated where your Kanzlei wants collective entries, and written out as a DATEV-Format booking batch - or delivered into DATEV Unternehmen online with the matching invoice PDFs where that suits the workflow.
Every document carries a stable Billbee invoice number, so the pipeline is idempotent by construction: a retry, a re-run, or a replayed webhook never produces a duplicate booking. Partial failures are isolated per document rather than failing the whole month, and anything that cannot be coded automatically is surfaced as a named exception instead of being silently dropped.
It runs on cloud-native, fully EU-hosted AWS infrastructure, so order and customer data stays in the EU and the AVV with your tax advisor stays clean under GDPR. Then we keep it running: monitoring, alerting, incident response, and watching Billbee’s and DATEV’s APIs for changes are our responsibility under contract, with a named owner and an SLA.
When this integration is worth building
If you sell on one channel, at one VAT rate, with fifty invoices a month, Billbee’s own exports plus twenty minutes in Excel are genuinely fine and we will tell you so. The integration earns its place when the channel count grows, when OSS and reverse-charge sales mix into the same order stream, when returns and marketplace payouts turn every close into a reconciliation exercise, or when your Kanzlei is billing you to repair exports that should have arrived correctly coded in the first place.
Frequently asked questions
- Billbee can already export invoice data. Why would I need an integration?
- Billbee's exports give you a flat list of documents. They do not know your Kontenrahmen, they do not assign tax keys, they do not split a multi-rate invoice into separate revenue lines, and they carry no channel-level clearing logic for Amazon or PayPal payouts. Someone still has to reshape every export in Excel before the Kanzlei will import it. The integration moves that logic into a pipeline that produces an import-ready Buchungsstapel without a human in the loop.
- Which DATEV target do you deliver into?
- Whatever your Kanzlei works with. Most commonly a DATEV-Format booking batch (the EXTF structure DATEV Kanzlei-Rechnungswesen imports), optionally accompanied by a Debitoren master-data file when individual debtor accounts are wanted. Where the workflow calls for it we also push the invoice PDFs Billbee already generates into DATEV Unternehmen online via the Rechnungsdatenservice, so each booking has its Beleg attached. We agree the target with your tax advisor before we build.
- Billbee does not carry Amazon or eBay fees. How do payouts reconcile?
- Correct, and this is the part people underestimate. Billbee knows the sale and the payment method, but marketplace commissions, fulfilment fees, and the netted payout live in the marketplace's own settlement report. We book the Billbee invoice against a per-channel clearing account (Geldtransit), then reconcile that account against the settlement data so the bank statement matches to the cent. If you do not want a second data source, we book the clearing account and leave the fee side to your advisor - we will say which option fits your volume.
- Do you book every invoice individually or as daily collective entries?
- Both are supported and it is a decision for your Steuerberater, not for us. High-volume marketplace sellers usually book daily collective entries per channel, per VAT rate, and per tax treatment against a Sammeldebitor, which keeps the Buchungsstapel readable. Where individual debtors are required, for example for B2B invoices with a VAT ID, we create and maintain the Debitorenstammsätze as well.
- Who operates the integration after it goes live?
- We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, with alerting and defined incident response. If Billbee changes its API or DATEV changes a format version, that is our contractual problem to solve, not something your finance team discovers on the tenth of the month. You get a named owner, an SLA, and a DPA covering the order and customer data we process.