DATEV and Orderful integration

What moves between them

The flow runs from Orderful into DATEV. ml-connector consumes inbound EDI transactions Orderful receives from trading partners, primarily 810 invoices and 850 purchase orders, and converts them into DATEV bookings. Invoice lines become EXTF CSV booking batches submitted to DATEV Rechnungswesen, mapped to the correct GL accounts, cost centers, and tax codes, while the underlying invoice PDF is uploaded to DATEV Unternehmen Online as an incoming-invoice document. Because DATEV EXTF bookings are write-only and its chart of accounts cannot be read back, ml-connector does not pull posted journals out of DATEV to send as outbound EDI; it treats DATEV as the accounting destination and Orderful as the document source.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the DATEV side it carries the user out through the OAuth Authorization Code with PKCE flow once, where the tax advisor or client approves access, then refreshes the 15-minute access token automatically using the client id only. Orderful uses a static API key sent on every request, scoped to the account region. Inbound transactions are received either from Orderful HTTP push or by polling buckets on a 5 to 10 minute interval, and each one is mapped to a DATEV EXTF booking batch with GL accounts, cost centers, and tax codes resolved first so every line lands on a valid account. The EXTF file is submitted as an async job and ml-connector polls the DATEV job status with exponential backoff until it completes or fails, since DATEV never pushes back. EXTF filenames are generated deterministically so a retry is recognized as a duplicate rather than double-posting, and DATEV document types are fetched per client before any PDF upload because they vary by client. Orderful 429 responses are retried using the Retry-After header, and 64-bit Orderful transaction ids are handled as strings so they do not overflow.

A real-world example

A mid-sized German consumer-goods distributor sells to large retail chains that require EDI and keeps its books in DATEV through an external tax advisor. Before the integration, every retailer invoice and purchase order that arrived over EDI was printed or exported from the EDI tool and typed into DATEV by hand, which delayed month-end and produced posting errors on tax codes and cost centers. With DATEV and Orderful connected, each inbound 810 invoice Orderful receives is posted into DATEV as an EXTF booking batch with the right accounts and tax keys, and the invoice PDF is filed in DATEV Unternehmen Online for the advisor to review. The manual data entry disappears and the books stay current with EDI activity.

What you can do

• •Turn inbound Orderful 810 EDI invoices into DATEV EXTF booking batches against the correct GL accounts, cost centers, and tax codes.
• •Upload the source invoice PDF into DATEV Unternehmen Online as an incoming-invoice document, using the client-specific document type.
• •Receive Orderful documents by HTTP push or polling buckets, and poll DATEV async job status until each booking completes.
• •Bridge the DATEV OAuth login that a tax advisor must approve with the static Orderful API key, refreshing the 15-minute token automatically.
• •Deduplicate submissions with deterministic EXTF filenames and retry Orderful 429 responses using the Retry-After header.

Questions

Which direction does data move between DATEV and Orderful?

The flow is Orderful into DATEV. Inbound EDI invoices and purchase orders that Orderful receives from trading partners are posted into DATEV as EXTF booking batches and uploaded as documents. DATEV EXTF bookings are write-only and its chart of accounts is not readable through the API, so ml-connector does not pull posted journals out of DATEV to send as outbound EDI.

How does the integration handle DATEV having no webhooks and async bookings?

DATEV does not push events, so every booking is submitted as an asynchronous EXTF or DXSO file job that returns a job id. ml-connector polls the DATEV job status endpoint with exponential backoff and jitter until the job reports complete or failed. On the Orderful side, inbound documents arrive by HTTP push or are pulled from polling buckets on a short interval, so neither system is assumed to confirm synchronously.

What stops the same EDI invoice from posting twice in DATEV?

DATEV detects duplicate EXTF submissions by the combination of filename and document type and rejects repeats, so ml-connector generates stable, deterministic filenames for each transaction. That makes a retry after a failed or timed-out job recognizable as the same file rather than a new posting. Orderful transaction ids are also stored after the first successful read so the same inbound document is not processed again.