DATEV and UPS integration
DATEV is the German accounting and tax backend, with an on-premise Rechnungswesen ledger and a Unternehmen Online cloud layer. UPS is a carrier platform that handles shipping, rating, and package tracking, not finance. Connecting the two means the shipping charges that UPS returns flow into DATEV as carrier-cost bookings, and UPS commercial invoices for international parcels land in Unternehmen Online as documents, without anyone re-keying them into the German books. UPS has no vendor, invoice, or general ledger objects, and publishes no billing download API at all, so the integration shapes the charge data UPS does return into DATEV postings rather than pulling accounting records UPS never holds. Because DATEV cannot read its own chart of accounts or posted journals back out, this is a one-way write into accounting.
What moves between them
The flow runs one way, from UPS into DATEV. ml-connector reads shipping charges from the UPS Shipping and Rating responses and the Quantum View manifest feed, matched to your purchase order numbers through the reference numbers carried on each package, and submits the resulting carrier-cost booking lines to DATEV as EXTF CSV files against the correct freight and tax accounts. UPS commercial invoices uploaded for international shipments are pushed into Unternehmen Online as documents, since DATEV holds the PDF while the booking carries the amount. UPS delivery and scan updates arrive from Track Alert 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 UPS is never written to.
How ml-connector handles it
ml-connector stores both credential sets encrypted. On the UPS side it requests a client-credentials bearer token and caches it for its full four-hour life, refreshing five minutes before expiry, because UPS caps token generation at roughly 250 requests per day and fetching one per call exhausts that budget fast; the 6-digit account number is sent as x-merchant-id at token time and as AccountNumber in requests so negotiated rates apply instead of retail. 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. Packages are tied back to your records by populating the UPS reference numbers with the purchase order at ship time, so a later Track reference lookup can match a shipping charge to the right purchase order. Each matched charge becomes EXTF CSV rows with Konto, Gegenkonto, Belegfeld 1, Buchungstext, and a Steuerschluessel 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 UPS service codes 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, UPS Track Alert deliveries are authenticated by checking the credential header because UPS sends no HMAC signature, 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 through UPS and keeps its statutory books in DATEV through its Steuerberater. Before the integration, an accounts payable clerk pulled shipping charges from the UPS Billing Center 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 UPS connected, each shipment's 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 UPS shipping charges from the Shipping, Rating, and Quantum View data into DATEV as EXTF CSV bookings against the correct freight and tax accounts.
- Match each UPS package to your records through the purchase order numbers carried as UPS reference numbers.
- Upload UPS commercial invoices for international shipments into DATEV Unternehmen Online with a stable GUID.
- Bridge the UPS four-hour client-credentials token, with its 250-per-day cap, to DATEV Authorization Code login with PKCE.
- React to UPS Track Alert 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 UPS?
- The flow is one way, from UPS into DATEV. Shipping charges, package detail, and customs documents move from UPS 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 UPS.
- UPS has no invoice API or general ledger, so what actually posts into DATEV?
- UPS is a carrier API with no vendor, AP invoice, or general ledger objects, and no billing download endpoint at all. What it does expose is shipping charge detail inside the Shipping and Rating responses and the Quantum View manifest feed, customs commercial invoices, and tracking, with the purchase order number carried only as a reference number on a package. ml-connector reads those charges, matches them to your purchase orders through the reference numbers, and posts them into DATEV as carrier-cost booking lines, mapping UPS service codes and surcharges to DATEV freight accounts and cost centers.
- How does the integration bridge the two very different logins and event models?
- UPS uses OAuth 2.0 client credentials with a roughly four-hour token that ml-connector caches and reuses, because UPS caps token generation at about 250 requests per day and fetching one per call exhausts that budget. 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. UPS pushes delivery events through its paid Track Alert webhook, authenticated by a credential header rather than an HMAC signature, while DATEV sends nothing back, so each EXTF booking job is confirmed by polling until it reports complete or failed.
Related integrations
More DATEV integrations
Other systems that connect to UPS
Connect DATEV and UPS
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started