Anyone who still views expense processes as administrative routine is underestimating their regulatory significance. From a financial accounting perspective, expense management today is above all one thing: a networked processing of personal data across system boundaries. That is precisely where the risks arise.

Because between travel booking, receipt scan, approval, posting, and reimbursement, data doesn't just move within a single tool — it travels through an entire ecosystem: TMCs such as Onesto or Atriis, HR systems, ERP platforms like SAP, accounting connections to DATEV, payment solutions, trustees, and external auditors. Every integration is therefore not only an efficiency gain, but also a checkpoint for data protection and information security.

Expenses are more sensitive than many process owners assume

In the expense context, it is rarely just a matter of an amount and a cost center. What gets processed regularly includes names, employee numbers, credit card or bank details, travel profiles, locations, hospitality information, and sometimes particularly sensitive details on receipts — relating to health, mobility, or personal circumstances. A hotel invoice, a taxi receipt, or a medical receipt incurred on a business trip can reveal considerably more than is visible at first glance.

This makes it clear: expense processing is personal data processing within the meaning of the GDPR and the revised Swiss Data Protection Act, the nDSG. Companies must therefore not only master the process itself, but also every data transfer between the systems involved.

Integrations are the real risk space

In many projects, the security of the core application is scrutinized intensively while interfaces are treated almost as an afterthought. That is exactly where the danger lies. The risk frequently sits not in the expense tool alone, but in the chain of APIs, imports, exports, webhooks, and middleware components.

As soon as master data is pulled from the HR system, card transactions are imported, posting entries are handed over to the ERP, or receipts are forwarded to financial accounting or the trustee, three questions must be answered clearly:

- What data flows specifically?
- Who is responsible for which processing step?
- What technical and organizational measures protect the transfer?

Without this transparency, a typical blind spot emerges: the integration works operationally, but is not regulatorily sound.

ISO 27001: important, but not sufficient

ISO 27001 is a strong signal in the expense context — nothing more, nothing less. The certification shows that a vendor has organized information security systematically, assessed risks, and anchored controls in an ISMS. For platforms with integration ambitions, this is practically the minimum standard today.

But what matters is operational implementation. In practice, finance managers should not just ask for the certificate — they should ask about the specific security mechanisms in place for integrations:

- encryption of data transfer and storage
- role concepts and least-privilege access
- client separation
- logging of access and data transfers
- incident and breach management
- defined deletion and retention policies
- governance of sub-processors and third-party partners

In short: ISO 27001 does not replace due diligence. Anyone procuring integrations must understand how security is technically implemented and where data actually resides.

GDPR and nDSG: the obligations lie with the company

In finance projects, there is a common assumption that the software vendor will bring compliance along with them. That is a misunderstanding. The vendor can support, document, and provide safeguards. But the responsibility for the lawful processing of employee data remains with the company doing the processing.

In expense management, this means in particular:

- defining legal bases and purposes clearly
- documenting data flows
- maintaining a record of processing activities
- informing data subjects transparently
- concluding data processing agreements
- reviewing international data transfers
- assessing technical and organizational measures
- conducting a data protection impact assessment where required

In the DACH context, there is an additional dimension: anyone operating in Germany, Austria, and Switzerland doesn't need a minimum standard — they need a robust framework that works across borders. The nDSG is not a lighter parallel regime, but in practice a distinct audit framework of its own, particularly when it comes to disclosures abroad and transparency obligations.

The most common weak point: unclear roles in the partner ecosystem

The more partners involved, the more important the legal classification becomes. Not every integration partner is automatically a data processor. Some act independently, others in joint controllership, and others still as sub-contractors of a vendor.

When these roles are not clearly defined, a liability risk arises. In my view, this is one of the most underestimated issues in modern finance stacks.

What is needed is not a paper exercise, but sound governance:

- a role matrix covering all systems involved
- data processing agreements where genuine commissioned processing takes place
- transparency about sub-processors in use
- clear rules for support access
- defined escalation paths in the event of security incidents

Particularly in API-based ecosystems, this clarity determines whether a company comes across as confident in an audit or improvised.

When a data protection impact assessment makes sense or is required

Not every integration automatically triggers a data protection impact assessment. But in the expense context, the threshold is reached more quickly than many expect — particularly when multiple data sources are linked, movement or travel data becomes systematically analyzable, sensitive receipt content is processed, or new transparency about employee behavior and habits emerges.

Anyone systematically bringing together travel bookings, expense data, HR master data, and payment information should not treat the DPIA question as a side note. A serious preliminary review also signals to data protection officers, auditors, and supervisory authorities that risks are not being addressed only after an incident has occurred.

What financial accounting should specifically require

For finance teams, this topic is no longer a purely IT question. Anyone selecting systems, approving integrations, or working with trustees and partners should insist on three things.

First: a traceable data flow map — not abstract, but specific to each integration.

Second: a robust contractual and role model — who processes what, in what capacity, and on what legal basis?

Third: a security proof that goes beyond marketing — ISO 27001 is good; what is more relevant is whether the level of control is adequate for the company's own process.

Conclusion

In expense management, compliance is determined not only within the app, but at the interfaces. Where systems exchange data, partners are involved, and processes interlock automatically — that is the real test for data protection and information security.

Anyone treating ISO 27001, GDPR, and nDSG as nothing more than a procurement checklist is thinking too narrowly. In finance, what is at stake is confidentiality, traceability, and liability. And ultimately also trust: from employees, from auditors, from partners, and from the company's own management.

Data security in integrations is therefore not a secondary matter. It is a leadership issue. Especially in the expense context.

Subscribe to the Edi Newsletter in German

The German Newsletter keeps you up to date about Edi: simply register using your e-mail address and never miss an article. Of course, you can unsubscribe at any time.