DATEV and ShipBob integration

What moves between them

The flow runs from ShipBob into DATEV. ml-connector reads ShipBob billing invoices and the fee transactions behind them, then writes them into DATEV as supplier bookings by submitting an EXTF CSV job to DATEV Rechnungswesen, mapped to the matching DATEV GL accounts, tax codes, and cost centers. The invoice PDF is uploaded to DATEV Unternehmen Online through the documents API as a Rechnungseingang so the tax advisor sees the source receipt next to the booking. Shipped-order and tracking data can be read for reconciliation, while inventory, products, and returns stay in ShipBob. DATEV bookings are write-only and ShipBob billing is read-only, so ml-connector never writes financial entries back into ShipBob.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the ShipBob side it runs the OAuth2 Authorization Code flow or uses a Personal Access Token, refreshes the one-hour access token, stores each rotated 30-day refresh token immediately, and sends the shipbob_channel_id header on every call. On the DATEV side it drives the PKCE Authorization Code flow through login mit DATEV, where the state parameter must be at least 20 characters, and it refreshes the 900-second access token using client_id only, never the client_secret. ShipBob billing webhooks such as billing.charge.created can trigger a run after HMAC-SHA256 verification, and a scheduled poll backfills anything missed, since DATEV cannot push. Each ShipBob invoice becomes an EXTF booking batch: ShipBob fee types map to DATEV GL accounts because the DATEV chart of accounts is not API-readable and must be configured in advance, amounts and tax codes are set on the Konto and Gegenkonto, and the PDF uploads to DUO as a Rechnungseingang. The EXTF submission is asynchronous, so ml-connector polls the job status with exponential backoff and treats the documented duplicate-file error as a stop signal by generating stable, deterministic filenames from the ShipBob invoice id. ShipBob has no idempotency header, so it dedupes on the invoice reference and a BullMQ jobId. EXTF files are written UTF-8 with precomposed NFC characters and a restricted filename character set, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A German direct-to-consumer brand with roughly 80 employees sells through its own online store and outsources warehousing and shipping to ShipBob, while its tax advisor keeps the books in DATEV. Before the integration, a bookkeeper downloaded each ShipBob billing invoice, split the pick, pack, ship, and storage fees by hand, keyed them into DATEV as a supplier booking, and emailed the PDF to the tax advisor for filing. Fees were posted late, tax codes were sometimes wrong, and the fulfillment costs never tied out at month-end close. With DATEV and ShipBob connected, each ShipBob invoice posts into DATEV as an EXTF booking against the right expense accounts, the PDF lands in DATEV Unternehmen Online automatically, and the manual split disappears. The fulfillment costs reconcile and close starts from accurate numbers.

What you can do

• •Post ShipBob billing invoices into DATEV as supplier bookings through EXTF CSV file import after each fulfillment cycle.
• •Map ShipBob pick, pack, ship, and storage fee types to the correct DATEV GL accounts, tax codes, and cost centers.
• •Upload each ShipBob invoice PDF to DATEV Unternehmen Online as a Rechnungseingang document for the tax advisor.
• •Bridge ShipBob OAuth2 with the DATEV login mit DATEV PKCE flow and refresh the 900-second DATEV token automatically.
• •Poll DATEV asynchronous import jobs with backoff, deduplicate on stable invoice filenames, and keep a full audit trail on every record.

Questions

Which direction does data move between DATEV and ShipBob?

The flow is ShipBob into DATEV. ShipBob billing invoices and their fee transactions move into DATEV as supplier bookings, and the invoice PDF uploads to DATEV Unternehmen Online. ShipBob is a fulfillment platform with no general ledger, so the chart of accounts stays in DATEV and ml-connector never writes financial entries back into ShipBob.

How does the integration handle DATEV bookings when DATEV has no webhooks and no synchronous posting?

DATEV bookings are submitted as asynchronous EXTF CSV jobs, so ml-connector sends the file, receives a job id, and polls the status endpoint with exponential backoff until it completes or fails. Because DATEV cannot push events, ShipBob billing webhooks and a scheduled poll drive the work instead. Stable, deterministic filenames derived from the ShipBob invoice id make a retry safe against DATEV duplicate-file detection.

Why are ShipBob fees mapped to accounts manually instead of pulled from DATEV?

The standard DATEV chart of accounts cannot be read through the API, so the GL accounts, tax codes, and cost centers for ShipBob pick, pack, ship, and storage fees are configured in ml-connector ahead of time. Each ShipBob fee type is mapped to a DATEV account and tax key so the EXTF booking lands on a valid Konto and Gegenkonto. This mapping is set once and reused on every invoice.