DATEV and FedEx integration

What moves between them

The flow runs one way, from FedEx into DATEV. ml-connector reads shipment, freight, and rate detail from FedEx, matched to your purchase order and invoice numbers through the customerReferences carried on each shipment, and submits the resulting carrier-cost booking lines to DATEV as EXTF CSV files against the correct freight and tax accounts. FedEx customs commercial invoices and freight billing documents are uploaded into Unternehmen Online as documents, since DATEV holds the PDF while the booking carries the amount. FedEx tracking updates arrive from Advanced Integrated Visibility webhooks where the subscription is enabled, and a scheduled poll of the Track API backfills the rest. Nothing flows back from DATEV: it cannot return its chart of accounts or posted journals, so DATEV is treated as a write-only accounting destination and FedEx is never written to.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the FedEx side it requests a client-credentials token and caches it for its full one-hour lifetime, because FedEx throttles token generation at the IP level and a burst of three token requests per second triggers a ten-minute 403, then sends the bearer token and account number on every call. On the DATEV side it runs the Authorization Code flow with PKCE, where the code challenge must use S256 and the state value is at least 20 characters, then holds the access token, which expires in 900 seconds, and refreshes it by sending only the client_id. Shipments are tied back to your records by populating customerReferences with P_O_NUMBER and INVOICE_NUMBER at ship time, so the later Track lookup can match a freight charge to the right purchase order. Each matched charge becomes EXTF CSV rows with Konto, Gegenkonto, Belegfeld 1, Buchungstext, and a tax code, written in UTF-8 with precomposed characters because non-normalized text is silently rejected, and filenames are kept deterministic so DATEV's filename-and-document-type duplicate check makes a retry safe. The customs invoice PDF is pushed to Unternehmen Online with PUT and a stable GUID after the client-specific document types are fetched first. The big gotcha is account mapping: DATEV will not hand over its chart of accounts, so FedEx service types and surcharges are mapped to known DATEV SKR freight accounts and Kostenstelle numbers in advance. Because DATEV processes asynchronously and sends no webhook, each EXTF job is polled with exponential backoff and jitter until it reports complete or failed, FedEx tracking webhooks are verified by HMAC-SHA256 before processing, and every job is replayable if a submission fails.

A real-world example

A mid-sized German e-commerce retailer with around 200 staff ships parcels and pallets through FedEx and keeps its statutory books in DATEV through its Steuerberater. Before the integration, an accounts payable clerk pulled freight charges from FedEx Billing Online and tracking exports, matched them to purchase orders in a spreadsheet, and typed the carrier-cost lines into DATEV by hand, while customs invoices for international orders were filed separately, which left freight accruals stale and produced posting and tax-code mistakes the tax advisor corrected at month-end. With DATEV and FedEx connected, each shipment's freight charge is matched by its purchase order reference and submitted to DATEV as an EXTF booking, coded to the right SKR freight account and cost center, and its customs invoice PDF is uploaded to Unternehmen Online within the polling window. The manual re-keying is gone and the tax advisor receives clean, complete carrier bookings.

What you can do

• •Post FedEx freight charges into DATEV as EXTF CSV bookings against the correct freight and tax accounts.
• •Match each FedEx shipment to your records through the purchase order and invoice numbers carried as customerReferences.
• •Upload FedEx customs commercial invoices and freight billing documents into DATEV Unternehmen Online with a stable GUID.
• •Bridge FedEx client-credentials OAuth, with its mandatory one-hour token caching, to DATEV Authorization Code login with PKCE.
• •React to FedEx tracking webhooks, poll the Track API to backfill, and poll each DATEV job to completion with retries and a full audit trail.

Questions

Which direction does data move between DATEV and FedEx?

The flow is one way, from FedEx into DATEV. Freight charges, shipment detail, and customs documents move from FedEx into DATEV as EXTF bookings and uploaded documents. DATEV cannot return its chart of accounts or posted journals through the API, so it is treated as a write-only accounting destination, and ml-connector never writes back into FedEx.

FedEx has no invoices or general ledger, so what actually posts into DATEV?

FedEx is a carrier API with no vendor, AP invoice, or general ledger objects. What it does expose is shipment and freight charge detail, customs commercial invoices, and tracking, with purchase order and invoice numbers carried only as reference fields on shipments. ml-connector reads those charges, matches them to your purchase orders through the customerReferences, and posts them into DATEV as carrier-cost booking lines, mapping FedEx service types and surcharges to DATEV freight accounts and cost centers.

How does the integration bridge the two very different logins and event models?

FedEx uses OAuth 2.0 client credentials with a one-hour token that ml-connector caches and reuses, because FedEx throttles token requests at the IP level and over-requesting triggers a ten-minute block. DATEV uses OAuth 2.0 Authorization Code with PKCE against Login mit DATEV and requires a real interactive user session, so a tax advisor or client signs in once to grant access, after which the 900-second token is held and refreshed automatically. FedEx pushes signed tracking events through its paid Advanced Integrated Visibility webhook, while DATEV sends nothing back, so each EXTF booking job is confirmed by polling until it reports complete or failed.