A consulting group wanted to connect a mobility budget provider to Workday. After months of contract negotiation the chosen solution fell through over unresolved integration requirements. An advertising services company already running another benefits platform for other benefits in kind solved its mobility budget integration provisionally through CSV reconciliation. An insurer with three German sites struggled with payroll errors, because each site had its own subsidy rules and payroll had to keep them apart by hand.
Three different companies, the same underlying situation. The HR and payroll integration decides whether a mobility budget becomes an efficiency gain or an additional manual task for HR. Before signing, this looks straightforward, because many providers advertise a smooth integration without defining precisely what that means in a specific tech stack. After signing it becomes clear that a SOAP interface, a REST API with OAuth tokens, and a CSV upload workflow are worlds apart, particularly when the HR stack is migrating in parallel or internal IT security requires several months of review.
This guide covers which integration routes work in practice, when each one fits, and how to set up a clean integration with the three most common German HR stacks, including during a live system migration.
Context for readers outside Germany: German payroll runs on wage types (Lohnarten), numbered categories that determine how each pay component is taxed and reported. Every subsidy has to map to the right wage type in the right legal entity. This is the detail that most benefit integrations underestimate.
Mobility budget providers frequently advertise smooth HR integration without defining what that means. In practice the phrase covers different realities, and the difference between them determines how much manual work lands on HR and payroll every month.
Mid-sized and large German companies rarely run a single HR system. A typical configuration is SAP HCM with payroll attached through a separate provider, alongside a planned move to SAP SuccessFactors. Personio is widely used in the mid-market, often combined with a DATEV payroll workflow or an external tax adviser. Workday appears in internationally oriented groups, usually next to a German payroll subsidiary system. A provider that understands only one of these configurations will produce manual workarounds in all the others.
In groups with their own IT security function, every new interface to SAP, SuccessFactors, or Workday is reviewed. One financial services company that wanted to set up an SAP interface for a mobility budget integration received approval only after more than a year of internal process. That lead time is not an outlier; it is typical for regulated sectors such as banking, insurance, and pharmaceuticals. The introduction must not wait on it, or the project slips from one quarter into the next.
Many companies are mid-way through an HR system change. A manufacturer planning a move to a new core HR system while simultaneously running a provider selection for a mobility budget faces a choice with two bad options. Building a native integration to the legacy system produces a stopgap that itself needs replacing within twelve months. Waiting for the new system delays the introduction by the full migration period.
Before signing anything, it should be clear which of the three routes is technically feasible in the specific stack, and which is realistic within the first project year.
Successful implementations frequently combine two of the three. A pilot in a single subsidiary starts on manual upload while the native API is prepared in the background for the wider introduction. That combination stops the whole project hanging on a single IT security review.
Create the work place of tomorrow with NAVIT. We are happy to support you with designing the best mobility solution for your company. Get in touch with us!
Contact us
A native API integration is often not feasible in the first project year for organisational or technical reasons. That is not a reason to postpone. Instead, companies can setup an alternative integration process.
Instead of an API, the platform pulls an export file from the HR system daily or weekly and synchronises eligibility, employee data, and subsidy rates from it. The delay is tolerable in day-to-day operation. For leavers and new joiners a manual push workflow should be available in addition. One advertising services company took this route and went live after three months without ever opening an interface.
CSV sync covers the majority of the workforce while a small pilot or senior group runs on the manual workflow with individual configuration. This is useful where senior employees have negotiated subsidy levels that differ from the standard.
Phase 1 with manual upload for the first 50 to 200 employees, phase 2 with CSV sync for the wider workforce, phase 3 with the native API once the IT security review has completed. This maps onto the pilot-to-group phase model in the multi-entity guide and reduces implementation risk considerably.
Two points matter across all three routes. The provider has to have documented what the later switch to the native API looks like. And the manual or CSV phase should not run longer than six to twelve months, or the workaround hardens and the native integration becomes a permanent open item.
Where a new HR system is being introduced in parallel, two projects with different logics collide. The HR system project is a long-term IT programme with a fixed go-live date, often 12 to 24 months. The mobility budget is a benefit project that wants a short go-live, often three to six months. Waiting for the HR system loses the benefit effect and with it the justification for the investment. Starting without regard for it risks doing the integration work twice.
Instead, integrate the data flow, not the HR system. The platform needs master data, eligibility, and lifecycle events. Those exist in every HR system regardless of vendor. A sync workflow that pulls from the legacy system today and the new one tomorrow is considerably more resilient than a native API that has to be rebuilt after the migration.
You can also use a CSV sync as the migration bridge. For the duration of the migration the integration runs on CSV export. Once the new HR system is live, it switches to the native API. This two-stage approach is clean because the first phase never builds a deep connection to the legacy system that the second phase would have to dismantle.
The wage type scheme in the payroll system frequently survives an HR system change. A platform that maintains the wage type mapping independently of the source HR system avoids having to reassign every subsidy after the migration.
Our mobility experts at NAVIT would love to share their knowledge with you about the new mobility product. Feel free to get in touch with us!
Get infoThe handover to payroll is where integration quality actually shows. An insurer with three German sites described the problem: where site A subsidises 100 % of the Deutschlandticket, site B 80 %, and site C provides a fuel card instead, payroll has to show the right wage type at the right amount for every individual. Without a structured handover, payroll errors accumulate and have to be corrected retroactively.
The wage type for a Deutschlandticket subsidy under § 3 Nr. 15 EStG can be called LA 4711 in subsidiary A and LA 8830 in subsidiary B. The platform has to carry that differentiation per client without HR assigning it by hand.
The relevant provisions include § 3 Nr. 15 EStG for the Deutschlandticket, § 3 Nr. 37 EStG for a company bicycle, and § 8 Abs. 2 Satz 11 EStG for benefits in kind inside the €50 monthly exemption limit. Every subsidy has to appear in payroll with the correct wage type and the correct tax treatment.
Subsidies post to the correct cost centre in the correct subsidiary rather than being allocated centrally. That matters for group controlling and for preparing a tax audit.
Every subsidy should be traceable: who became eligible, when, at what level, and on the basis of which rule. In a tax audit or a dispute with the works council, that audit trail is the defence.
Payroll teams rarely examine these points at this depth before contract signature. They become visible three months in, once the first payroll runs have completed. A properly configured platform should offer a dry run with sample data so payroll can check the export in full before go-live.
A mobility platform processes personal data about employees: master data, joining and leaving dates, commuting information, subsidy rates. That is processing on behalf of the controller within the meaning of Article 28 GDPR and requires a data processing agreement. Three points should be settled before signature.
A data processing agreement under Article 28 GDPR with a sub-processor list. It sets out which data is processed for which purpose, who processes it as a sub-processor (hosting providers, payment service providers, transport associations issuing the Deutschlandticket), and how data is returned or deleted at the end of the contract under Article 28(3)(g) GDPR. It belongs in every IT security assessment.
Data categories and retention periods. The platform should document which categories it actually collects (master data, settlement data, reporting aggregates) and which it does not (movement profiles, real-time GPS, personal travel history beyond what settlement requires). That documentation is also useful in the works council negotiation.
A data protection impact assessment under Article 35 GDPR. In groups with a developed data protection practice, the data protection officer will require one before go-live. A prepared template from the provider reduces the internal effort considerably.
For the IT security assessment, certifications (ISO/IEC 27001, and TISAX in automotive), hosting location, penetration testing documentation, and the incident response process are also relevant. These belong in a structured security questionnaire early, ideally at the RfP stage rather than after signature.
NAVIT supports all three integration routes, meaning the native API connection, the CSV or SFTP-based HRIS export, and manual upload, and can migrate between them without significant rework for HR or payroll. That matters in a multi-entity context, because subsidiaries can run different HR systems and the platform should carry that heterogeneity without separate configuration strands.
In groups with a live HR system migration the integration typically runs in two stages. CSV synchronisation acts as the bridge during the migration, and the native API takes over once it completes. The platform configuration stays identical; only the data source changes. That decoupling avoids implementing twice.
For the payroll handover, NAVIT provides entity-specific wage type mappings with a configurable scheme per subsidiary, automatic tax construction per benefit type, and an audit trail across all subsidies.
MERKUR PRIVATBANK KGaA reduced administrative effort for mobility benefits by around 90 % after introduction. The comparison basis is documented: employees previously submitted receipts for Deutschlandtickets they had bought themselves, which then had to be checked, settled, archived, and reimbursed through payroll. Those steps no longer occur. Implementation took three months, integrated with Sage.
On data protection, NAVIT supplies a prepared data processing agreement under Article 28 GDPR with a sub-processor list, a record of processing activities, and a template for the data protection impact assessment. These are the standard starting point in an IT security review.
How long does integration with a standard HRIS take?
Eight to sixteen weeks for a fully native API connection to SuccessFactors, Workday, or Personio, depending on IT security lead time. Four to eight weeks is realistic for a CSV-based HRIS export. Manual upload can be productive in two to four weeks but only makes sense for a pilot or a transition.
What happens if IT security rejects or delays the native API?
A plan B built on CSV sync is the standard route. The introduction can go live without waiting for the native integration. Once IT security approves, the switch to the API happens without data migration or a second implementation.
Can the integration be set up during a live SAP migration?
Yes, though not as a native API to the legacy system. Use a CSV bridge, then switch to the native API to the new system once the migration completes. That avoids building the integration twice.
How is the payroll handover done in DATEV or another payroll system?
Through an entity-specific payroll export with configurable wage type mapping per subsidiary. The tax construction (§ 3 Nr. 15 EStG, § 3 Nr. 37 EStG, § 8 Abs. 2 Satz 11 EStG, § 40 Abs. 2 Satz 2 Nr. 2 EStG) is applied automatically per benefit type.
Which data does the platform process, and which does it not?
Processed: master data for eligibility, settlement data for the payroll handover, aggregate data for reporting. Not processed: real-time movement profiles, personal travel history beyond what settlement requires, or third-party data. The full list is in the record of processing activities.
What does the data processing agreement negotiation look like?
NAVIT supplies a prepared agreement as a standard contract. In most groups the negotiation need is limited, because the main data protection requirements are already covered. Groups with their own templates will want to compare against their internal standard, which typically takes two to four weeks.
Disclaimer: NAVIT accepts no liability for the accuracy of the information provided. The content on our website is for general information purposes only and does not constitute tax or legal advice. It cannot and is not intended to replace individual, binding tax and legal advice addressing your specific circumstances. All information is provided without warranty as to accuracy or completeness.
Sign up for our newsletter to receive the latest insights about our mobility solution products like the 49 eurojob ticket.
