Choose finance software by testing whether you can recover usable records from it before you commit. An export button is only the start: check the fields, attachments, relationships and reporting history you would need in another system. A small migration rehearsal reveals more than a promise that your data remains yours.
This matters for bookkeeping, invoicing, expense management and payment operations. You may leave because the product becomes expensive, lacks a required feature or no longer serves your country. You may also need a temporary archive because access is interrupted.
The method below is a buyer’s test, not a ranking of current products. It uses synthetic records and distinguishes a successful export from a successful migration.
Define what you would need to take with you
Start from the work the software performs. An invoicing system may hold customers, invoices, credit notes, payment allocations and source documents. An accounting system adds accounts, journals, balances and reporting relationships. An expense system may hold receipts and approval history.
List the records that support your business obligations and day-to-day decisions. A PDF of an invoice is useful, but it may not preserve the structured information needed to reconcile hundreds of invoices in another application.
Conversely, a transaction CSV may preserve amounts while omitting the receipt or approval trail that explains them. Treat structured records, documents and history as separate parts of the export question.
Do not assume that every feature migrates automatically. Xero’s official conversion guidance, for example, describes several distinct import tasks and data types. It illustrates why moving into a finance system is a mapping exercise rather than one universal upload.
Ask about exports at the plan you will buy
Check the actual subscription tier and user permissions. A feature shown in a demonstration may require a higher plan, an administrator role or an additional service. Record those conditions before comparing prices.
Ask whether you can export data yourself, whether there are date-range or record-count limits, and whether attachments can be exported in bulk. Find out what happens after cancellation, including any read-only access and its duration.
An API can provide another route, but it is not automatically a complete archive. Check which objects and fields it exposes, whether historical records are accessible, and what rate limits or pagination rules affect a full extraction.
Get answers from current documentation or a written vendor response. A broad sales statement such as “full portability” is less useful than a list of exportable objects and known exclusions.
Build a small but awkward test company
Create synthetic records in a trial or approved test workspace. Avoid entering real customer details merely to test an export. The test should include the cases likely to expose missing relationships and formatting problems.
A useful starter set includes two customers with similar names, an invoice with several line items, a partial payment, a credit note, a foreign-currency invoice, a receipt attachment and a corrected contact address.
Give the records recognisable identifiers such as DEMO-CUST-01 and DEMO-INV-101. Use clearly fictional contact information and no usable bank details. Keep a separate expected-results sheet describing what you entered.
Include a leading zero in one identifier and punctuation in a description. These ordinary details reveal whether a spreadsheet or import process silently changes data. If the business needs multilingual names, include representative synthetic text in the relevant writing systems.
Inspect the exported fields
Open the export in a tool that lets you control text encoding, delimiters and data types. A spreadsheet can automatically interpret identifiers as numbers or dates, so keep the original file unchanged and inspect a working copy.
Check that identifiers remain intact, decimal separators are consistent and dates have an unambiguous format. Verify that each amount has the necessary currency and that tax components remain distinguishable from the gross total.
The following is a test checklist, not a promise that every product uses the same fields:
| Record | Details to look for |
|---|---|
| Customer | Stable identifier, legal name, addresses and relevant tax fields |
| Invoice | Identifier, customer reference, dates, currency, status and totals |
| Line item | Description, quantity, price, tax information and invoice reference |
| Payment | Amount, currency, date and allocation to one or more invoices |
| Credit note | Its own identifier and the invoice or balance it adjusts |
| Attachment | Original file, readable name and connection to its record |
| History | Changes or approvals needed for your use and obligations |
Do not judge completeness from the number of rows alone. An export can contain every invoice while losing the links that show which payments settled them.
Reconcile relationships, not just totals
Use the synthetic partial payment to test the connection between invoice and payment records. If an invoice for 1,200 has a payment of 700, the remaining amount should be 500 under the simplified test assumptions.
Now add a credit note of 100 applied to that invoice. The remaining amount becomes 400, assuming no other transactions. Check that the export lets another system reproduce that result without reading a free-text note manually.
Compare customer balances, outstanding invoices and control totals before and after import. A grand total can match even when payments are assigned to the wrong customers, so inspect individual relationships too.
For foreign-currency records, distinguish the original transaction amount from the accounting or reporting-currency amount. Preserve the exchange-rate information needed to explain the conversion. A single number labelled amount may be insufficient.
Document any transformation needed for the destination system. Renaming columns is a different level of effort from reconstructing thousands of payment allocations from PDFs.
Check documents and the history behind them
Open exported attachments and verify that they are complete and readable. A filename ending in PDF does not prove the file contains the expected invoice or receipt. Sample documents from different dates and record types.
Look for a stable way to connect each file with its structured record. An archive containing 5,000 receipts named with random identifiers may be technically complete but difficult to use without a mapping file.
Ask what the export omits: comments, approval events, edits, deleted records, bank-feed metadata or links to external documents. Not every omission is a deal-breaker, but important omissions need an explicit retention or migration plan.
Retention obligations vary by jurisdiction and record type. Determine what your business actually needs with appropriate professional advice rather than assuming that a vendor’s default retention period satisfies it everywhere.
Rehearse the destination, even a simple one
An export is most useful when you can do something with it. Import the synthetic records into the intended destination or a neutral working table and try to answer ordinary questions: which invoices are unpaid, which payment settled a bill, and where is the supporting document?
Record the manual work required. If a small test takes an hour because every field needs repair, estimate what that means at the business’s actual volume. A cheap subscription can create an expensive exit project.
Do not claim a full migration succeeded because a destination accepted a CSV. Verify record counts, important totals, relationships, document access and a sample of reports. Keep the original source exports so you can investigate discrepancies.
If a conversion partner is involved, ask exactly which history is included, which dates it covers, how corrections are handled and what evidence of reconciliation you receive. Define acceptance before scheduling the real move.
Check access and operational dependencies
Identify who owns the account and who can export it. A business should not depend on a departed employee’s personal email or a contractor’s sole administrator login to retrieve its records.
Use supported roles so routine users have the access they need and authorised administrators can maintain continuity. Record the process for adding and removing users, including what happens to documents or approvals they created.
Review connected services. Bank feeds, payment processors, expense cards and automation tools may need separate exports or reauthorisation during a move. Their data may not all live in the finance application itself.
Our account security guide covers recovery and shared operational dependencies. Portability and access belong together: an excellent export feature is useless when no authorised person can sign in to use it.
Price the cost of leaving
Compare the subscription alongside setup, integrations, export restrictions, specialist conversion and staff time. Do not invent a precise exit cost from incomplete information; use a range and list the assumptions.
For example, a fictional product costing $30 less per month saves $360 per year. If its missing payment allocations would require a one-time manual reconstruction costing $900, that trade-off deserves attention. The example does not prove the more expensive product is better; it shows why the subscription is only one component.
Consider whether the product’s useful features justify the dependency. Lock-in is not always a reason to reject a service. It is a cost to understand and manage, especially when the product handles records the business must retain.
Keep the decision tied to actual needs. An advanced API is valuable only if someone can use and maintain it. A simple documented export may be more dependable for a small team than a custom extraction script no one understands.
Keep an exit pack current
Once the product is in use, maintain a documented export routine appropriate to the business. Include structured data, required attachments, key reports and notes about mappings or exclusions. Protect the archive because it may contain sensitive financial and personal information.
Check that exports remain usable after major product changes. A new column name, altered status field or changed attachment route can break a previously successful import process.
Keep a brief inventory with the export date, period covered, file counts and checks performed. Avoid labelling an archive complete when certain modules were intentionally excluded.
When the time comes to leave, choose a cut-off date, reconcile balances and define which system is authoritative during the transition. Running two systems without a clear boundary can create duplicate invoices or inconsistent payment records.
Questions
Does a CSV export mean my data is portable?
It provides a starting point. Check the fields, relationships, attachments and history needed to reproduce your records in another system.
Should I test portability with real customer data?
Use synthetic records first. They let you test awkward cases and known answers without unnecessarily sharing confidential information.
What is the most useful migration test?
Reproduce a small set of invoices, partial payments, credit notes and attachments in a destination, then reconcile both individual records and totals.
Can I cancel the old account immediately after importing?
Only after confirming access, reconciliation, required records and the vendor’s cancellation terms. An accepted import file alone does not establish a complete migration.
