WooCommerce Accounting: Invoices, Payments and DATEV

In short: WooCommerce gives you the orders. The money flows through your payment providers, and the bookkeeping happens in your accounting software or at your accountant. Clean WooCommerce accounting connects these three levels: invoice, payment and journal entry have to match, including refunds and amounts that cross the month-end.

Exporting a single order is easy. Whether your workflow really holds only shows with a partial refund, a second import or a payment that is paid out in the following month. This guide explains the basics first and then gives you seven tests to check your current workflow or a new tool before handing data over to DATEV. It is written for businesses established in Germany.

Who supplies which data?

The shop. WooCommerce knows orders, line items, customers, shipping costs, tax rates, discounts and refunds. These produce the revenue you have to book.

The payment providers. PayPal, Stripe and other providers document which money actually arrived, which fees they retained and when they paid out. Your bank account usually receives a batch payout instead of each individual customer payment.

The accounting side. Your accounting software or your accountant assigns transactions to accounts and tax codes, clears open items and prepares VAT returns and annual accounts.

Problems almost always arise at the handovers: when an order cannot be matched to a payment, when fees are missing or when two systems create the same revenue. How payment provider payouts are broken down is covered in the article on payment provider accounting.

How are invoices created in WooCommerce?

WooCommerce can send order emails out of the box. One of them is the "Order Details" email, which you send manually from the order screen to share invoice details and a payment link (WooCommerce documentation on emails). The documentation does not mention a PDF invoice or sequential invoice numbers there.

For German business practice, you therefore usually need a separate invoicing process, for example through an extension or an external invoicing tool. Check the mandatory invoice details under section 14(4) of the German VAT Act, including a sequential invoice number. If you sell to business customers in Germany, e-invoicing applies as well: you have had to be able to receive e-invoices since 2025, and transitional rules for issuing them run until the end of 2026 or 2027 (section 27(38) UStG). More on this in the article on e-invoicing in e-commerce.

Which export routes are there?

Before you compare extensions, describe the step that is missing today. Are invoices missing? Are the documents there, but payments unresolved? Or do the entries not fit your accountant's import?

Approach	When it can fit	What else to check
Invoicing process connected to your accounting software	Documents and customer data should be transferred	Payment reconciliation, fees and later corrections
Export for your accountant, for example in DATEV format	An agreed data set should be handed over in the required format	Completeness, account assignment and existing entries
Data preparation across several sources	Shop data, payment providers and other channels need to be combined	Supported files, references and special cases

The routes can complement each other. If your invoicing tool already transfers sales reliably, you do not need a second process that creates the same revenue again. Often, only the link to the payment movements is missing. That various WooCommerce connections exist for transferring documents is shown, for example, by the Lexware Office software ecosystem (in German).

Sales to other EU countries

If you deliver to consumers in other EU countries, the VAT of the destination country can apply instead of German VAT. Your export then has to show the delivery country and the tax rate applied. Whether and how you report such sales through the OSS scheme is something to clarify with your accountant. The basics are covered in the article on OSS and IOSS.

Prepare a meaningful test month

Choose a closed month for which orders, invoices and payment data are complete. Also consider opening balances and payouts that arrive only in the following month.

Note the active payment providers, the invoicing system and the data transfers already set up. Record which source creates which transaction. A table with source, period, file name and processing status is enough to start with.

Keep the original files unchanged and test with copies. Changes to an export file should remain traceable; otherwise you cannot tell later whether a difference comes from the shop, the export or the reworking.

Test 1: An order can be found through its references

Pick a closed order and look for it on three levels: in the shop, in the invoicing process and in the payment provider's data. Note the order number, invoice number and payment reference. These identifiers do not have to be identical, but how they belong together must be traceable.

The test is passed if you can get from the order to the matching invoice and payment without relying only on an identical amount. Two purchases of €79 each cannot be told apart by price alone.

Test 2: A partial refund is visible on both sides

Take an order of €119 and a partial refund of €29. In the simplified payment case, €90 remains with the merchant before fees and other movements. Check the original transaction, the invoice correction and the actual repayment.

WooCommerce distinguishes automatic and manual refunds. A manually recorded refund does not return the money by itself, and a mere status change does not trigger a repayment. With a partial refund, the overall order status also does not have to change to "Refunded" (WooCommerce documentation on refunds).

This test is met if the correction in the shop is linked to the actual payment event and the related document. A status field alone is not sufficient evidence.

Test 3: The month-end does not create an apparently missing payment

Pick a sale near the end of the month whose payout reaches your bank only in the following month. Record order, invoice, payment at the provider and bank payout as separate points in time. Which period applies for accounting and tax purposes depends on your case; the payout does not replace the other data.

The case is solved if you can trace the amount across the cut-off date and the later bank receipt clears the open payout amount. Also agree with your accountant which time zone applies to reports. Systems with a different day boundary show transactions around midnight in different daily lists.

Test 4: Fees and invoices create the expense only once

For PayPal or Stripe, check a payout with its fee information. Distinguish payment movement, fee evidence and expense entry. If an import already records the fees as an expense, the later document must not create the same expense again. If the payment data only serves to clear items, the fee has to be booked in full elsewhere.

You pass if, for a selected fee, you can explain exactly where the expense arises and how the document is linked to it.

Test 5: A second import does not create unnoticed duplicates

A technical error, a supplemented export file or a change of staff can lead to a period being imported again. Test this case only in a test environment or with a safe preview, and document beforehand which records have already been processed.

Your workflow is in good shape if it is clear whether known transactions are skipped, updated or flagged as a conflict. Neither silent duplication nor an unnoticed loss of new information is acceptable. Also ask about changed orders: a refund added later is different from an unchanged copy.

Test 6: The export fits your shop

Check on selected orders whether all details your accounting workflow needs are included: amounts, currency, dates, references, shipping costs, delivery country and line item information. Not every CSV file contains the same information. A sales analysis report serves a different purpose than an export for accounting, and the available fields depend on your setup and extensions.

The test is done if all required details are available or you have agreed on a clear additional source. Missing values must not be silently replaced with default assumptions. Document in particular how mixed baskets, discounts and shipping costs are handled.

Test 7: Your accountant can follow the test month

Hand over the data set with a short overview: sources used, periods, known exceptions and existing entries. Ask your accountant to check a sale, a fee, a partial refund and a month-end transition. Keep technical import messages separate from accounting questions.

You have reached the goal if the data can be used in the target system and the selected cases can be traced with their documents. A file that opens does not meet this requirement yet. A document number in a journal entry also does not mean that the document itself can be opened in your accountant's environment.

Turn the tests into a decision

Rate each test as "passed", "open" or "failed", and for open points add a responsible person and the concrete change. A single special case does not have to rule out a tool. What matters is whether you can handle it repeatedly with reasonable effort.

Recurring rework belongs in the cost comparison. Measure the time for the whole workflow: obtaining exports, checking files, resolving differences and handing over data. A fast transfer is worth little if hours of corrections follow. More checkpoints for choosing a tool are in the guide on choosing e-commerce accounting software.

WooCommerce with KudTax

You connect WooCommerce to KudTax via API, so your shop data arrives continuously. Alternatively, you upload exports as CSV or XLSX files, for example for past periods; whether an export fits is then checked against its columns and contents. The WooCommerce integration page describes both routes.

You connect PayPal and Stripe as separate data sources. KudTax matches the orders with payments and payouts using AI assistance, keeps open differences visible and creates journal entries based on SKR03 or SKR04 from the reconciled data. These go out via DATEV export or to tools such as Lexware Office and sevdesk; year-end closing and tax returns stay with you or your accountant.

KudTax is free for up to 25 orders a month, and larger plans can be tried free for one month: create an account. If you would rather look at your export together first, book a demo and bring the seven test cases.

Frequently asked questions

Does WooCommerce create invoices?

WooCommerce sends order emails, including "Order Details" with invoice details and a payment link. For PDF invoices with sequential numbers and the mandatory German invoice details, you usually need an extension or an external invoicing tool.

Is an invoicing plugin enough for my WooCommerce accounting?

That depends on the open task. If invoices are transferred completely and the payment side is already reconciled, your existing setup may be enough. Additional data preparation becomes interesting when fees, refunds or several sources regularly need manual clarification.

Is every WooCommerce export suitable for DATEV?

No. Data content, file structure and booking logic have to match the agreed import. A list of orders is not yet a checked posting batch.

Do I have to switch my accounting software for KudTax?

No, KudTax complements your existing workflow. Clarify the supported handover route for your system and test it with a limited period.

Should I import all past orders first?

Start with a defined test period and record which transactions are already in the target system. Plan larger back imports only once responsibilities, completeness and duplicate handling are settled.