Who Actually Owns the SAF-T Process? Tax, Finance, IT, or Everyone?

We talk to finance teams, tax advisers, and IT departments across Europe every week. They ask about schema versions, XML namespaces, validation errors, and file size limits. But the question that comes up more than any other has nothing to do with technology. It’s simply: whose job is this?

SAF-T compliance sits at the intersection of tax law, accounting data, ERP systems, and regulatory deadlines. No single department owns all of those things. And that’s why the ownership question causes so much friction.

Why the Question Keeps Coming Up

In most organisations, SAF-T lands on someone’s desk without much ceremony. A tax authority requests a file. A new country mandate appears. An auditor mentions it during a routine review. And then the scramble begins: who’s supposed to produce this file, who checks it, and who takes responsibility if it’s wrong?

The problem is structural. Traditional corporate functions weren’t designed with SAF-T in mind. Tax teams understand what the authority wants but rarely have direct access to the ERP. Finance teams own the data but may not know the regulatory requirements in each country. IT teams can extract and format the file but have no way of judging whether the contents are correct. So the process falls between the cracks, with each team assuming someone else is handling it.

The Four Teams That Touch SAF-T

Every organisation is different, but SAF-T compliance typically involves four groups. Understanding what each one brings to the table is the first step towards sorting out who should own what.

The Tax Team

Tax professionals are usually the ones who know a SAF-T obligation exists in the first place. They track country mandates, understand what the tax authority is looking for, and manage the relationship with auditors. In countries like Luxembourg, where FAIA files are requested on demand during VAT audits, the tax team is the first point of contact when the authority comes knocking.

The catch is that tax teams rarely sit inside the ERP. They may review the final output, but they depend entirely on other departments to produce it. A tax director who can’t generate the file independently ends up accountable for something they don’t fully control.

Finance and Accounting

The finance function owns the underlying data. The general ledger, chart of accounts, customer and supplier master records, tax codes, journal entries: all of it lives in the accounting system and flows directly into the SAF-T file. If the chart of accounts doesn’t map cleanly to the local SAF-T format, or if customer records are missing tax identification numbers, the resulting file will fail validation before it ever reaches the tax authority.

Controllers and accounting managers are usually the first to spot data quality issues. They know which accounts are active, which ones are dormant, and where the gaps are. In Luxembourg, FAIA requires French-language account type labels (Actif, Passif, Produit, Charge) and specific TVA codes. If those aren’t set up correctly in the accounting system, the file won’t pass validation, let alone the business rules.

IT and ERP Teams

When it comes to actually producing the file, that almost always falls to IT. Whether the organisation runs SAP, Oracle, Microsoft Dynamics, or a smaller accounting package, someone needs to configure the extraction, map data fields to the SAF-T schema, and produce a valid XML file. In many companies, IT also handles the testing and submission infrastructure.

The challenge for IT teams is context. They can build a technically valid XML file without understanding whether the data inside it is correct. A file might pass all the structural checks while containing account references that don’t match across sections, or tax rates that aren’t recognised by the local authority. Technical validity and regulatory compliance are two different things, and IT teams are typically equipped for only the first.

External Advisers

Plenty of organisations bring in external tax advisers or consultants, particularly for a first SAF-T implementation or when expanding into new jurisdictions. The Big Four all offer SAF-T readiness reviews, and there are specialist firms that focus on nothing else. These assessments look at whether an organisation’s systems, processes, and data are fit for purpose.

External help is valuable for bridging knowledge gaps, but it doesn’t solve the ownership question. Once the adviser leaves, someone internal still needs to run the process, keep data quality in check, and respond when the tax authority asks for a file.

What Happens When Nobody Owns It

The consequences of unclear ownership are predictable, and we see them regularly:

A Practical Model for SAF-T Ownership

The organisations that handle SAF-T well tend to follow a similar pattern. They don’t hand it to one department alone. Instead, they split ownership into three layers.

This three-layer model mirrors how most organisations already handle statutory financial reporting. The CFO is ultimately accountable. A specialist function (in this case, tax) runs the day-to-day process. And the execution teams (finance and IT) do the hands-on work. The key difference is making this structure explicit for SAF-T rather than leaving it implied.

The Multi-Country Complication

For businesses operating across borders, the ownership question gets harder still. Each country has its own SAF-T variant, its own filing requirements, and its own deadlines. Poland’s JPK requires monthly VAT file submissions. Norway’s SAF-T Financial is requested on demand during audits. Romania’s D406 is monthly. Luxembourg’s FAIA is on demand during VAT audits.

A multinational can’t rely on a single local team to manage all of this. What works well is a central tax function that sets standards and monitors compliance, with local finance and IT teams responsible for execution in each jurisdiction. The central team defines the process, the data quality requirements, and the validation standards. Local teams produce the files and handle country-specific nuances.

This is particularly relevant now that SAF-T adoption across Europe is accelerating. With Bulgaria launching its mandate in 2026 and several other countries expanding their requirements, the number of jurisdictions a central tax team needs to cover is growing every year.

Data Quality Is the Real Battleground

Whoever owns the process on paper, the single biggest factor in SAF-T success or failure is data quality. And data quality isn’t something you fix at the point of file generation. It’s the result of months or years of consistent accounting practice.

The most common data issues we see in FAIA validation relate to master data: incomplete customer or supplier records, chart of accounts entries that don’t match the local standard, tax codes that are outdated or incorrectly mapped, and broken references where an account ID used in a journal entry doesn’t actually exist in the reference data.

These are accounting problems, not IT problems. They need someone in the finance function to maintain clean, complete, and correctly coded master data on an ongoing basis. That’s why the execution layer of SAF-T ownership has to include finance, not just IT. Treating SAF-T as a purely technical exercise is a reliable way to end up with files that are structurally valid but riddled with data errors.

How Validation Fits into Ownership

One thing that really helps clarify ownership is introducing a validation checkpoint before any file goes to the tax authority. Rather than waiting for the authority to find errors, teams can catch problems in advance and sort them out while there’s still time.

Validation works at two levels. Schema validation checks that the file is technically sound: correct structure, valid data types, all the required fields present. Business rule validation goes deeper, checking that account references match up, tax codes are valid for the jurisdiction, totals balance correctly, and that the data is internally consistent.

The value of validation for the ownership question is that it gives each team a concrete role. IT produces the file. Finance reviews the validation results for data quality issues. Tax reviews for regulatory compliance. If validation is built into the process as a routine step rather than an emergency measure, the handoffs between teams become predictable rather than chaotic.

The Luxembourg Perspective

In Luxembourg, the ownership question has a particular flavour. FAIA files are not submitted on a regular schedule. They are requested by the Administration de l’Enregistrement et des Domaines (AED) during a VAT audit, and businesses typically have a limited window to respond. This on-demand model means that readiness is everything. You can’t start figuring out who owns the process when the request lands on your desk.

Companies established and VAT-registered in Luxembourg, subject to the standard chart of accounts, with a turnover above EUR 112,000 and more than roughly 500 annual transactions are within scope. For these businesses, the practical advice is straightforward: assign a named individual as the SAF-T process owner, ensure they have a working relationship with both the accounting team and IT, and test the file generation process at least once a year, even if no audit is imminent.

There’s also a legislative development worth watching. Bill 8186B proposes extending FAIA obligations beyond VAT to cover direct tax reporting as well. If this goes ahead, it will broaden the scope of data required and make the case for clear ownership even stronger.

Five Steps to Get Ownership Right

So Whose Job Is It?

SAF-T isn’t a tax problem. It isn’t an IT problem. It isn’t an accounting problem. It’s all three at once, which is why ownership is the question we hear more than any other. The organisations that get this right don’t try to force it into a single silo. They treat it as a shared process with a named owner, clear responsibilities at each stage, and a validation step that keeps everyone honest.

The technology is the easy part. Schemas can be looked up. XML can be validated. Extraction scripts can be written. The hard part is getting three departments to work together on something that none of them fully owns. That’s a people problem, not a technical one. And it’s the one worth solving first.