The integration conversation usually starts with optimism. Your ERP holds the financial data; your new reporting or forecasting tool needs that data. The vendor has shown you a live demo where the connection is established in minutes. The integration guide lists your ERP as a supported connector. Everything looks straightforward.
Then the project starts, and you discover that "supported connector" covers a range of realities — from a deeply tested, bidirectional integration with automatic schema mapping to a CSV export function that your team needs to trigger manually and upload monthly. The difference between these two ends of the spectrum has a large effect on what your finance team actually gets out of the tool and how much ongoing work the integration creates.
The 12 questions below are designed to surface that difference before you sign, not after.
Questions About Data Access and Architecture
1. Does the integration use your ERP's native API, or does it rely on file exports?
This is the foundational question. A native API connection means the financial software can pull data directly from your ERP in near-real-time, without any manual intervention. A file-based integration — even one that's automated — introduces a step that can fail silently: the export runs, but the file format changes after an ERP update, or the file lands in the wrong folder, or the import scheduler misses a run.
For Nordic mid-market ERPs specifically: Fortnox provides a well-documented REST API that supports invoice, payment, and journal ledger reads. Visma's API ecosystem varies across product lines — Visma eEkonomi and Visma Administration have different API coverage than Visma Business. Ask the vendor which specific Visma product and API version they've tested against, not just "Visma" as a category.
2. What data objects does the integration read, and which ones does it write back?
Most financial software reads from the ERP. Some also write back — posting journal entries, updating cost centre codes, or flagging invoices for payment. Understand which direction data flows for every object the integration touches. Write-back integrations introduce a risk that errors in the connected tool propagate into your authoritative accounting records. This isn't a reason to avoid write-back integrations, but it is a reason to require a clear audit trail and a documented rollback procedure.
3. How does the integration handle the chart of accounts mapping?
Your chart of accounts is the taxonomy that organises every transaction in your ERP. A new tool needs to map its own category structure to your chart of accounts. This mapping is rarely as simple as it looks. Account code conventions differ between companies, and the mapping from a generic "cost category" in a reporting tool to your specific account codes requires careful configuration.
Ask the vendor: is the chart of accounts mapping done during setup by your team, by the vendor's implementation team, or automatically? If automatic, how does it handle accounts that don't map cleanly to the tool's taxonomy? How does it handle custom accounts that you've added to a standard chart? Gaps or errors in this mapping will produce categorisation mistakes that are often not visible until someone looks closely at the underlying data.
Questions About Data Quality and Governance
4. How does the integration handle partial periods and mid-month data?
Financial data is rarely clean at the point it's pulled from an ERP mid-period. Invoices are posted but not yet approved. Accruals are in draft. Bank reconciliations are partially complete. Ask the vendor what their tool does with draft or unposted transactions. Does it include them, exclude them, or flag them as provisional? There's no single right answer — it depends on your use case — but an integration that silently includes unposted journals will produce materially incorrect interim figures.
5. What happens when the ERP data changes after it's been synced?
In practice, ERP data gets corrected. Invoices get voided and re-issued. Journal entries get reversed. Bank reconciliation items get restated. Ask how the integration handles these retrospective changes. Does it re-sync historical data when source records are modified? Does it maintain a change log that preserves the original value and the corrected value? If the integration takes a point-in-time snapshot and doesn't update retrospectively, your reporting tool's historical data will diverge from your ERP's audit trail over time.
6. What is the data residency and transfer mechanism?
For Nordic companies, this has regulatory weight. Your financial data is subject to GDPR. If the integration routes your ERP data through servers outside the EEA — even transiently, for processing — the vendor needs to have appropriate safeguards in place: Standard Contractual Clauses, an adequacy decision, or equivalent. This isn't a theoretical concern; it's a documented GDPR obligation for any data controller handling personal data (which financial records frequently contain — employee names, customer names, supplier contacts).
Ask specifically where data is processed and stored during transit and at rest. "Our servers are in Europe" is not a sufficient answer — ask for the specific data centre locations and the subprocessor list.
Questions About Operational Reliability
7. What is the SLA on sync frequency and uptime?
An integration that syncs once daily at 2 a.m. is fundamentally different from one that syncs every 15 minutes or on-demand. For cash flow monitoring and working capital tracking, the sync frequency determines how stale your data can be. Understand both the advertised sync frequency and the guaranteed minimum — these are often different numbers.
8. How will your team know if the integration fails?
Integration failures are common and often silent. The sync runs, encounters an authentication error or a schema mismatch, fails, and the dashboard shows data that's 48 hours old with no visible indication that anything is wrong. Ask how the tool surfaces integration failures: email alerts, in-app warnings, a status indicator on the data feed. Then ask how many customers have been affected by silent failures in the past 12 months. The answer to that second question tells you more than the feature documentation.
9. What does re-authentication look like after an ERP credential rotation?
API credentials expire. ERP user passwords get rotated as part of IT security policy. OAuth tokens have defined lifespans. When that happens, the integration will break until it's re-authenticated. Ask how re-authentication works: is it a self-service flow that a finance team member can complete in five minutes, or does it require an IT admin and a support ticket? For a small finance team with limited IT support, a re-authentication process that takes days is a significant operational risk.
Questions About Implementation and Ongoing Support
10. What does the implementation project actually involve — on your side?
Vendors routinely understate the implementation effort required from the customer. "Setup takes 30 minutes" often describes the time required to enter credentials and enable the connector, not the time required to validate the chart of accounts mapping, clean up historical data quality issues, configure category rules, and train the finance team. Ask for a project plan that specifies tasks, expected hours, and who is responsible for each task — vendor side and customer side. Compare that plan with what your team actually has capacity for.
11. How is the integration maintained when your ERP releases a major update?
ERP vendors release API changes periodically. Sometimes these are additive. Sometimes they deprecate endpoints that your integration relies on. Ask who is responsible for monitoring ERP API changelogs and updating the integration connector accordingly. Is it the vendor's engineering team, with a defined response time? Or does it become your team's problem when the integration breaks after an ERP update?
12. Can you see a sample of the data that comes through before you sign?
This is the most practical pre-signature test. Ask the vendor to connect to a sandbox or demo ERP environment and show you exactly what the synced data looks like — not a cleaned-up demo dataset, but raw synced records. Check whether the transaction categorisation, entity mapping, and date handling look correct for your specific setup. A vendor who resists this request has either not tested the integration against your ERP variant or has something to hide about the data quality.
Integration failures are one of the most common reasons that financial control software projects stall after launch. The questions above don't guarantee a smooth integration — no checklist can do that — but they ensure that you understand what you're getting before the project starts rather than discovering the gaps during it. The goal is to make informed trade-offs, not to find a perfect integration that doesn't exist.