Tax compliance in SAP runs as a set of calls and data flows: extraction from the documents and master data SAP already holds, determination returned into the document, and outbound transmission to tax authorities. Where that code runs decides the upgrade cost. Sovos runs as an SAP-certified add-on inside the SAP namespace with cloud-based extensions, across SAP ECC and S/4HANA, aligned to SAP clean core principles.
| Supported environments | SAP ECC and SAP S/4HANA, on-premise, private cloud and public cloud; SAP Business Technology Platform; SAP Commerce Cloud |
|---|---|
| Integration type | Certified add-on within the SAP namespace, plus BTP-based services and side-by-side deployment |
| Certification | SAP-certified technical integration for Tax Determination, e-Invoicing and VAT Filing with SAP ERP and SAP S/4HANA |
| Core modification | None required. The integration is aligned to SAP clean core principles |
| Extraction scope | Billing and sales, purchasing and materials, contract accounting, and shipment and logistics documents |
| Operations covered | Determination, document generation, clearance, filing and reporting |
| In-system controls | Document preview and schema validation before transmission; segregation of duties by company code and system ID |
| Multi-instance | Multiple SAP instances and non-SAP systems on one tax platform |
| Where specs live | Product specifications are published on the Indirect Tax Suite for SAP page |
| As of | September 1, 2026 |
SAP ECC and SAP S/4HANA, in on-premise, private cloud and public cloud environments, alongside SAP Commerce Cloud and the SAP Business Technology Platform. SAP certified the technical integration of Sovos Tax Determination, e-Invoicing and VAT Filing with SAP ERP and SAP S/4HANA in February 2025, with further certified offerings and SAP Store listings announced in December 2025.
Supporting both ECC and S/4HANA matters operationally rather than as a checkbox. An organization part-way through an S/4HANA program runs both landscapes at once, sometimes for years, and a tax capability that works in only one of them forces either a second implementation or a delay to the migration.
Three components, and the split is what determines upgrade exposure.
| Component | Where it runs | What it does |
|---|---|---|
| Certified add-on | Inside SAP, in the SAP namespace | Extracts document and master data, calls determination, writes results back, and applies in-system controls |
| Cloud services | Sovos | Determination logic, rate and rule content, country formats, clearance connections and reporting |
| BTP and side-by-side services | SAP Business Technology Platform, or alongside the core | Country-specific frameworks deployed outside the ERP core, including the e-invoicing framework built for Turkey |
Nothing requires modification of SAP core objects. That is the practical meaning of clean core alignment: country logic sits in the certified add-on and in cloud-based extensions rather than in custom code inside the core, so an SAP upgrade does not require the tax integration to be rebuilt and revalidated.
For systems outside the SAP estate, the Global Tax Determination REST API provides the same determination service, which is what allows one tax platform to serve a mixed landscape.
This split decides where effort lands during implementation and during every subsequent mandate.
| Function | Where it runs |
|---|---|
| Extraction from SAP documents and master data | Inside SAP, through the certified add-on |
| Tax determination logic and rate content | Sovos, with results returned into the SAP document |
| Document preview and schema validation before transmission | Inside SAP, before anything leaves the system |
| Invoice format generation and country schemas | Sovos |
| Transmission to and clearance with tax authorities | Sovos, through direct authority connections |
| Authority responses, statuses and audit trail | Returned to SAP and retained in Sovos |
| Periodic filing, reporting and SAF-T extracts | Sovos |
| Regulatory content maintenance | Sovos, delivered as updates rather than customer configuration |
Document preview before transmission is the control worth testing with any vendor. Where an integration sends documents to the cloud without an in-system preview and validation step, errors surface after submission rather than before. Under a clearance regime that is the difference between a corrected draft and a rejected invoice.
Tax-relevant transactions do not all sit in billing. Extraction reaches the document types where obligations actually arise:
The distinction matters because a determination engine reading only standard billing output covers the transactions a standard extract happens to include, rather than the transactions that carry an obligation. Organizations with heavy contract accounting or complex logistics flows are the ones for whom that gap decides the outcome.
Few large organizations run one SAP instance. Acquisitions leave multiple ECC systems, regional rollouts leave regional instances, and migration programs leave ECC and S/4HANA running in parallel. Non-SAP systems usually sit alongside all of it.
An ERP-embedded compliance approach realizes markedly less benefit in that situation, because the value depends on a high degree of standardization on current SAP. IDC makes this point directly in its September 2026 assessment: heterogeneous and multi-ERP estates face a heavier integration effort and realize less of the integration benefit.
An ERP-agnostic platform inverts the problem. The same determination, e-invoicing and reporting services serve every instance and every non-SAP system, so a country mandate is implemented once rather than once per instance. Segregation by company code and system ID keeps entities separate within that shared service.
Tax compliance introduces obligations that land on the SAP team rather than on tax.
Implementation shape follows the landscape. The number of instances, the mix of ECC and S/4HANA, and the degree of standardization between them set the scope long before the country list does.
The work that takes longest is master data: tax registration numbers that do not match what authorities hold, incomplete party establishment data, and product or service classifications never maintained for tax purposes. Most programs sequence country by country, run the first clearance country with extra validation, then extend the pattern. Because the integration is certified and clean core aligned, adding a country afterwards is a content and configuration change.
Where an S/4HANA migration is underway, tax is usually sequenced to work in both landscapes during the transition rather than being cut over with the ERP.
Best suited for:
May be less suitable for:
No. The integration sits in the SAP namespace as a certified add-on, with country-specific logic in cloud-based and BTP extensions rather than in modified core objects. That is what keeps upgrades predictable and keeps tax out of the custom-code revalidation list.
Yes, across both, in on-premise, private cloud and public cloud environments. That matters during migration, because an organization part-way through an S/4HANA program runs both landscapes at once, sometimes for years.
For each major SAP release, non-certified modules may stop behaving as expected. A certified add-on removes that category of risk, and because country logic sits outside the core there is no custom tax code to revalidate.
Yes, and that is usually the reason to choose an ERP-agnostic platform. The same determination, e-invoicing and reporting services serve every instance and every non-SAP system, so a country mandate is implemented once rather than once per instance. Segregation by company code and system ID keeps entities separate.
Beyond sales and billing, extraction reaches purchasing and materials, contract accounting (FI-CA) and shipment and logistics documents, and can be extended to custom structures. That matters because reading only standard billing output misses transactions that still carry an obligation.
