ERP Architecture / Data Portability
ERP portability is becoming a finance operating advantage.
ERP portability is becoming a practical finance advantage. The EU Data Act gives CFOs, controllers, and ERP buyers a reason to make exports, lineage, retrieval windows, deletion proof, and balance tie-outs part of everyday system design. The upside is optionality: cleaner migrations, stronger audit response, better AI-ready data, and more leverage in vendor decisions.
Thesis: portability is a control design pattern for modern finance teams.
The Data Act is easy to read as a legal or procurement event. Finance teams should read it as an operating design prompt. If an ERP can move data between services without losing meaning, finance can also use that same discipline for acquisitions, carve-outs, audit samples, reporting backups, AI data preparation, and vendor governance.
The European Commission says the Data Act applies since 12 September 2025 and includes minimum requirements for switching between data processing services. It also says Software as a Service providers must make open interfaces available and, at minimum, export data in a commonly used, machine-readable format. That is the regulatory baseline. The finance baseline is higher: the export must preserve accounting meaning.
Accounting meaning lives in relationships. An invoice is linked to a supplier, purchase order, receipt, approval, tax treatment, payment, bank statement line, journal entry, attachment, workflow state, and close sign-off. A useful ERP portability design keeps those relationships intact and gives finance evidence that the exported package reconciles.
The facts finance teams should design around.
Requirement
Application date
Sourced fact
The European Commission says the Data Act applies since 12 September 2025.
ERP implication
ERP buyers should treat portability as a live due-diligence requirement with current acceptance evidence.
Requirement
Cloud and SaaS switching
Sourced fact
The Commission says Chapter VI covers switching between data processing services, including cloud and edge services.
ERP implication
Finance teams should test whether their ERP can export useful operational data, workflow evidence, and configuration context.
Requirement
Open interfaces and formats
Sourced fact
The Commission says Platform as a Service and Software as a Service providers must make open interfaces available and export data in a commonly used, machine-readable format at minimum.
ERP implication
The export should be a controlled finance data product with reconciled structure and complete lineage.
Requirement
Switching charges
Sourced fact
EUR-Lex Article 29 says providers must not impose switching charges from 12 January 2027.
ERP implication
Procurement can shift evaluation from exit-fee negotiation to evidence that switching will actually work.
Requirement
Contract evidence
Sourced fact
EUR-Lex Article 25 requires written contractual terms around switching, including exit-strategy support and categories of portable data and digital assets.
ERP implication
Controllers should ask for the contract, data dictionary, migration runbook, security plan, and deletion evidence as one package.
Requirement
Accounting implications
Sourced fact
BDO notes that the Data Act may affect how cloud services and software providers recognize revenue and manage contracts.
ERP implication
SaaS finance teams should align legal terms, billing, revenue operations, renewals, and customer-success data around the same exit rights.
The operating model: inventory, manifest, preserve, validate, retrieve, erase.
Strong portability starts before anyone wants to leave a vendor. Finance should know which data objects exist, which controls they support, which fields reconcile, and which configuration choices make those records meaningful. The export should be repeatable enough to test during normal operations.
Step
Finance data inventory
What happens
Map ledgers, subledgers, vendors, customers, invoices, bills, approvals, payments, bank statements, allocations, schedules, attachments, and configuration dependencies.
Evidence to retain
Data catalog record, owner, source system, retention policy, export field list, and reconciliation target.
Step
Export manifest
What happens
Produce a signed inventory of every table, file, API response, attachment set, hash, timestamp, and row count included in an export.
Evidence to retain
Manifest ID, export job, schema version, data counts, file hashes, exceptions, and approver.
Step
Lineage preservation
What happens
Keep relationships between documents, journals, approvals, integrations, workflow states, and GL postings intact during extraction.
Evidence to retain
Source IDs, foreign keys, event IDs, posting references, approval chain, and transformation log.
Step
Configuration portability
What happens
Capture chart of accounts rules, approval policies, tax mappings, entity hierarchy, close calendar, dimensions, roles, and integration mappings.
Evidence to retain
Configuration snapshot, effective date, change request, owner, and migration note.
Step
Security continuity
What happens
Keep access controls, encryption approach, export approvals, retrieval windows, and deletion evidence visible to finance and IT owners.
Evidence to retain
Requester, role, approval, transfer method, encryption key owner, retrieval deadline, and deletion certificate.
Step
Reconciliation test
What happens
Prove that exported finance facts can rebuild balances, open items, schedules, and audit samples in a neutral environment.
Evidence to retain
Trial balance tie-out, AP/AR aging tie-out, deferred revenue tie-out, sample evidence, and reviewer sign-off.
Finance portability starts with a manifest.
The manifest is the control point. It tells the controller what was exported, when it was exported, who approved it, which schema was used, how the files were hashed, which exceptions occurred, and whether the exported balances tie out. Without that manifest, a data export is only a technical artifact.
The manifest also reduces cost. A buyer, auditor, integration partner, or acquiring finance team can inspect the same evidence instead of asking engineering to recreate the export history. Good portability design makes future work cheaper because the data contract is already explicit.
Export evidence example
{
"export_manifest_id": "port_2026_q3_eu_data_act_0042",
"source_system": "cloud_erp_primary",
"entity_scope": ["nl_subsidiary", "de_subsidiary"],
"period_scope": ["2026-04", "2026-05", "2026-06"],
"schema_version": "finance_export_v3",
"objects": [
{ "name": "general_ledger_entry", "rows": 184203, "hash": "sha256:..." },
{ "name": "ap_invoice", "rows": 12419, "hash": "sha256:..." },
{ "name": "approval_event", "rows": 39104, "hash": "sha256:..." },
{ "name": "attachment_link", "rows": 18777, "hash": "sha256:..." },
{ "name": "configuration_snapshot", "rows": 642, "hash": "sha256:..." }
],
"controls": {
"requested_by": "controller_eu",
"approved_by": ["security_owner", "finance_system_owner"],
"encryption": "customer_managed_key",
"retrieval_deadline": "2026-08-15",
"balance_tie_out": "passed",
"deletion_evidence_required": true
}
}Implementation checklist.
- Add ERP portability to vendor scorecards before renewal, migration, acquisition integration, or finance transformation work begins.
- Ask every ERP and finance app vendor for its Data Act switching position, export formats, API coverage, exit runbook, retrieval period, deletion evidence, and fee schedule through January 2027.
- Define a minimum finance export package: ledger facts, subledger facts, master data, open items, schedules, approvals, attachments, integration events, workflow state, and configuration snapshots.
- Run a quarterly portability drill on a small but complete slice of data, such as one entity, one period, one bank account, and ten audited transactions.
- Make row counts, checksums, source IDs, foreign keys, and balance tie-outs part of the export acceptance checklist.
- Store export evidence inside the finance control environment so audit, legal, IT, procurement, and the controller can answer the same questions from the same record.
- For SaaS providers, align sales contracts, billing, revenue recognition analysis, customer-success playbooks, and technical migration tooling around the same switching promises.
- For buyers, treat portability as optionality: it improves acquisition integration, backup reporting, AI data preparation, audit response, and vendor leverage even when no migration is planned.
Constructive failure modes to design around.
Exports are technically available but operationally thin
Expand the export from tables to finance meaning: account balances, open items, approvals, attachments, and configuration context.
The data dictionary stops at field names
Add ownership, source event, validation rule, transformation history, and downstream reconciliation target.
Attachments move without evidence links
Keep source documents tied to transactions, approvals, payment releases, audit samples, and retention rules.
The exit test happens only during a crisis
Run small drills during normal operations so finance learns the gaps before a renewal, incident, or migration.
Security and finance evidence split into separate workstreams
Treat export approval, encryption, retrieval, deletion, and balance tie-out as one control pack.
SaaS teams treat the Data Act as legal wording only
Connect contract terms to billing, revenue operations, customer migration tooling, and support metrics.
Questions for ERP, finance app, and implementation vendors.
The demo should show more than an export button. Ask the vendor to walk through a real finance object from source transaction to export package to independent validation. The strongest vendors will show the data, the relationships, the exceptions, and the control evidence without making finance rely on custom engineering work.
Can you export ledger, subledger, workflow, attachment, integration, and configuration data with source IDs and relationship integrity preserved?
Can finance users see an export manifest with row counts, checksums, schema versions, exceptions, and approval evidence?
Which data and digital assets are portable, which are excluded, and how are trade-secret exclusions documented without delaying the switching process?
Can a customer run a partial portability drill without terminating the contract or opening a professional-services project?
How do you preserve audit evidence for approvals, SoD policy, period locks, payment releases, bank reconciliations, and close sign-offs?
What changes before 12 January 2027 when switching charges must be removed under Article 29?
For SaaS providers, how are customer exit rights reflected in revenue recognition analysis, contract operations, billing, and renewal workflows?
For buyers, how does your implementation partner validate balances and open items after export into a neutral review environment?
The practical path forward.
Start with a small, high-value portability drill. Pick one entity, one period, and a representative set of AP, AR, cash, close, and configuration records. Export them with a manifest. Rebuild the balances in a neutral environment. Record the gaps. Then turn those gaps into the next sprint for data governance, integration design, and vendor negotiation.
Done well, Data Act readiness can make finance systems better even when no migration happens. Controllers get better evidence. CFOs get stronger vendor leverage. Operators get cleaner data contracts. ERP buyers get a sharper question than feature parity: can this system preserve accounting meaning when the data has to move?
Sources
- European Commission: Data Act explained
- EUR-Lex: Regulation (EU) 2023/2854, the Data Act
- European Commission: Data Act policy page and Legal Helpdesk
- European Commission: cloud computing policy and Cloud and AI Development Act context
- BDO: EU Data Act SaaS Accounting Awareness Brief
- Maples Group: The EU Data Act switching framework
- Eversheds Sutherland: Data Act contract changes for SaaS business