Receipt images and structured invoice data
→
DATEV DESTINATIONDATEV Unternehmen onlineStatus visible in the product
We connect your software to DATEV.
Rechnungsdatenservice 1.0 transfers receipt images and structured invoice data from an application to DATEV Unternehmen online. Lohnaustauschdatenservice exchanges employee, salary, absence and monthly payroll data bidirectionally with DATEV payroll systems. We build OAuth, mapping, statuses and failure handling directly into your product.
Two data flows with different jobs.
We first define which data moves from which system and in which direction. This determines the appropriate DATEV data service, required permissions and business mapping.
ERP or cloud application→DATEV Unternehmen online
Transfer invoices and receipts
Rechnungsdatenservice 1.0 transfers digital receipt images as well as structured invoice and cash data. DATEV receives the receipt data; structured invoices can then support posting proposals in DATEV accounting.
- Receipt images
- Invoice and cash data
- Transfer status
HR or specialist application↔DATEV payroll
Exchange payroll data in both directions
Lohnaustauschdatenservice connects employee master data, salary components, absences and monthly transaction data with DATEV LODAS or DATEV Lohn und Gehalt.
- Employee and salary data
- Absences
- Monthly transaction data
What we implement technically.
The integration runs server-side and handles authentication, data quality and operation as one connected product flow.
- OAuth 2.0 and OpenID Connect
The backend runs the Authorization Code Flow with PKCE and manages access and refresh tokens. The browser does not call DATEV endpoints directly.
- Permissions and metadata
Before transfer, we check which datasets, clients and business contexts are available to the signed-in DATEV user.
- Mapping and validation
Source fields are mapped explicitly to DATEV structures. Missing information and invalid formats become visible before transfer.
- Statuses, failures and retries
Success and failure states appear in the product. Failed operations can be corrected and sent again in a controlled way.
- Technical logging
Requests, responses and DATEV transaction identifiers are logged for support and diagnosis without exposing business content unnecessarily.
From sandbox to production approval.
We test the critical data flow early and work through DATEV requirements step by step until the integration is ready for production.
- Define the data flow
Set the source, DATEV destination, direction, data types and business owner.
- Integrate the sandbox
Set up the app and API product; implement OAuth, mapping, statuses and failure handling with test data.
- Prepare approval
Review the complete flow against general and data-service-specific DATEV requirements.
- Accept production
Confirm access, monitoring, logging and operational ownership for ongoing use.
What we need for an initial assessment.
With this information, we can identify the data service, missing access and the next useful technical test.
- Source system
Name, version and technical contact for the application.
- DATEV destination
Unternehmen online, LODAS, Lohn und Gehalt or another DATEV product.
- Direction
Data into DATEV, out of DATEV or in both directions.
- Sample data
Two or three anonymised records including required fields and exceptions.
- Access
Existing DATEV accounts, Developer Portal organisation and testing options.
- Business owner
Someone who can decide mappings, exceptions and expected outcomes.
Questions before the first technical test.
Which DATEV data service fits our case?＋
The product name alone does not decide this. The source and destination, data types, transfer direction and subsequent business process are the relevant inputs. We clarify these four points at the start.
Do we already need a DATEV account?＋
Not for an initial assessment. For sandbox and production testing, however, we need the intended DATEV accounts, permissions and a responsible contact on the customer side.
When can effort and timing be estimated reliably?＋
Once the data service, authentication, field mapping, test dataset and relevant exceptions are known. Before that, a fixed estimate would mainly be an assumption.
Which data should move from which system to DATEV — or back?
Tell us the source, destination, data types and transfer direction. We will identify the relevant DATEV data service and the prerequisites still missing before a meaningful estimate.