Which direction does data move between DATEV and BigCommerce?

It moves one direction, from BigCommerce into DATEV. Orders, payment transactions, and refunds are read from BigCommerce and submitted to DATEV as EXTF or DXSO bookings, with invoice PDFs uploaded to DATEV Unternehmen Online. DATEV booking imports are write-only and DATEV sends no webhooks, so no financial data flows back into the store.

How are bookings confirmed if DATEV has no webhooks?

DATEV processes EXTF and DXSO submissions as asynchronous jobs, so ml-connector submits each job and then polls its status endpoint with exponential backoff until it reports complete or failed. Sandbox runs only a structural check and does not validate business rules, so confirmation is treated as final only against production. A failed job is surfaced and can be replayed.

What maps to the DATEV general ledger if BigCommerce has no GL accounts?

BigCommerce has no chart of accounts, so ml-connector maps order totals, tax, shipping, and refunds onto DATEV GL accounts and cost centers that you configure up front. DATEV does not expose its full chart of accounts over the API, so those account numbers, such as SKR03 or SKR04 entries, must be set in the mapping rather than discovered. Every booking line then references an account and cost center that already exists in DATEV.

DATEVBigCommerce

DATEV and BigCommerce integration

DATEV runs accounting and tax for German businesses. BigCommerce runs an online store. Connecting the two moves every sale, payment, and refund from the storefront into the books without re-keying. ml-connector reads BigCommerce orders and turns them into finalized DATEV bookings, posted as EXTF CSV files to the Rechnungswesen ledger or as DXSO XML jobs to DATEV Unternehmen Online, with the invoice PDF filed alongside. It handles the very different APIs on each side and submits the data on the schedule you choose.

How DATEV works

DATEV is split between an on-premise Rechnungswesen ledger and the DATEV Unternehmen Online cloud. A REST surface covers only client lookup and document uploads; the actual bookings go in as asynchronous batch jobs, either EXTF CSV files to the ledger or DXSO XML jobs to DUO, each submitted and then polled for completion. Authentication is OAuth2 Authorization Code with PKCE through login.datev.de, with a 15-minute access token and a real tax-advisor or client login required. DATEV sends no webhooks, posted journal entries cannot be read back, and the full chart of accounts is not available over the API.

How BigCommerce works

BigCommerce exposes orders, line items, order transactions, refunds, customers, and catalog products through its REST Management API, using v2 for orders and v3 for transactions and refunds. Every request carries a static access token in the X-Auth-Token header from a store-level API account. BigCommerce also pushes webhooks for order and refund events, signed with an HMAC-SHA256 X-BC-Signature keyed on the app client secret, though each payload is only a stub with the resource type and ID, so the full record is fetched from the REST API. BigCommerce has no GL accounts, vendors, or purchase orders.

What moves between them

The flow runs one direction, from BigCommerce into DATEV. When an order is paid, ml-connector reads the order, its payment transaction, and any refund from BigCommerce, builds a booking with the order total, tax, shipping, and the right debit and credit GL accounts, and submits it to DATEV as an EXTF CSV job or a DXSO XML job. The invoice or receipt PDF is uploaded as a document to DATEV Unternehmen Online against the correct client. Refunds post as offsetting bookings. Because DATEV booking imports are write-only and DATEV publishes no webhooks, nothing financial flows back from DATEV into the store.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the BigCommerce store access token and the DATEV OAuth2 client, refreshing the 15-minute DATEV access token with the client ID alone and re-running the PKCE login when the refresh token lapses. New sales can arrive two ways: a BigCommerce order or refund webhook, verified with the HMAC-SHA256 X-BC-Signature before anything is trusted, or a scheduled poll of the orders endpoint for stores that prefer pull. Either way the stub is expanded into the full order via the REST API. Each order becomes an EXTF CSV booking for the ledger or a DXSO XML job for DUO, with store totals, tax codes, and cost centers mapped to GL accounts that already exist in DATEV, since the chart of accounts cannot be pulled and must be configured up front. EXTF filenames are generated deterministically so a retry is not rejected as a duplicate, and every DATEV job is polled with backoff until it confirms, because DATEV gives no synchronous result. Failed submissions carry a full audit trail and can be replayed.

A real-world example

A German consumer-goods brand sells direct to shoppers on BigCommerce and keeps its books in DATEV through its Steuerberater. Before the integration, a bookkeeper exported the order list every week, summed sales, VAT, shipping, and refunds by hand, and keyed the totals into DATEV while filing each invoice PDF separately, which left the ledger days behind the store and made VAT returns slow to assemble. With DATEV and BigCommerce connected, each paid order posts as a booking with its VAT code and cost center the moment payment clears, refunds post as offsets, and the invoice PDF lands in DATEV Unternehmen Online automatically. The books stay current with the store and month-end VAT work starts from data that is already reconciled.

What you can do

Post BigCommerce orders into DATEV as EXTF CSV or DXSO XML bookings with totals, VAT, and shipping split out.
Book BigCommerce refunds and payment transactions as offsetting entries in the DATEV ledger.
Upload each invoice or receipt PDF to DATEV Unternehmen Online against the correct client.
Bridge the BigCommerce static X-Auth-Token and DATEV PKCE login, refreshing the 15-minute access token automatically.
Verify BigCommerce webhook signatures, then poll each DATEV job to confirmation with retries and a full audit trail.

Questions

Which direction does data move between DATEV and BigCommerce?: It moves one direction, from BigCommerce into DATEV. Orders, payment transactions, and refunds are read from BigCommerce and submitted to DATEV as EXTF or DXSO bookings, with invoice PDFs uploaded to DATEV Unternehmen Online. DATEV booking imports are write-only and DATEV sends no webhooks, so no financial data flows back into the store.
How are bookings confirmed if DATEV has no webhooks?: DATEV processes EXTF and DXSO submissions as asynchronous jobs, so ml-connector submits each job and then polls its status endpoint with exponential backoff until it reports complete or failed. Sandbox runs only a structural check and does not validate business rules, so confirmation is treated as final only against production. A failed job is surfaced and can be replayed.
What maps to the DATEV general ledger if BigCommerce has no GL accounts?: BigCommerce has no chart of accounts, so ml-connector maps order totals, tax, shipping, and refunds onto DATEV GL accounts and cost centers that you configure up front. DATEV does not expose its full chart of accounts over the API, so those account numbers, such as SKR03 or SKR04 entries, must be set in the mapping rather than discovered. Every booking line then references an account and cost center that already exists in DATEV.

Connect DATEV and BigCommerce

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started