Bookkeeping software data portability is your ability to take your records out of a tool in a form another tool can read. For a practice, that means client transactions, categorization rules, coded history, original documents and settings. Check the export for each before you sign up, because the gaps usually appear only when you try to leave.
What data can you take when leaving a bookkeeping software vendor?
When you leave a bookkeeping software vendor, you can usually take the data you put in and the transactions the tool produced. What is harder to take is the work the tool did on your behalf: learned patterns, rule logic, review history and audit trails. Those are often stored in a shape only that vendor's product understands.
Sort what a practice holds in any bookkeeping tool into three groups:
- Inputs. Uploaded statements, receipts and documents. These are your clients' files and should always come back in their original form.
- Outputs. Extracted and categorized transactions, export files and reports. These usually come out as CSV or a spreadsheet.
- Know-how. Rules, account mappings, vendor names you cleaned up, notes on held lines and learned coding. This group is where portability is weakest.
The third group is the one that hurts to lose. A practice can re-upload statements in an afternoon. Rebuilding a year of decisions about how each client's vendors are coded can take weeks.
Whose data is it?
The client owns the records about their business. You hold them under your engagement. The vendor stores them under its terms of service. Read the terms for what happens to data when an account closes, how long it is kept and whether you can ask for deletion. A vendor that cannot answer those questions plainly is a risk to your clients, not just to you.
Export formats that keep bookkeeping data portable
A portable export format is one that another program can open without the original vendor's software. For bookkeeping data, that usually means CSV or a spreadsheet for transactions and rules, PDF for documents, and a standard ledger import file for posted entries. A proprietary backup file is not portable, however complete it looks.
The table lists six kinds of data, a format that travels well and the question to ask a vendor about each.
| Data | Portable format | Question for the vendor |
|---|---|---|
| Original statements and documents | The original PDF or image | Can I download every original in bulk, by client? |
| Extracted transactions | CSV with one row per line | Does the export include date, description, amount, balance and account? |
| Categorization rules | CSV with match pattern and target account | Can I export rules, or only view them on screen? |
| Coded history | CSV with the final account per line | How many months can I export at once? |
| Account mappings per client | CSV or spreadsheet | Is the mapping exported with the client, or kept separately? |
| Review notes and approvals | CSV or a report | Is there any record of who approved what? |
Columns matter as much as the format
A CSV that leaves out the running balance or the account code is portable in name only. Open a sample export and check every column you would need to rebuild the client in a new tool. If the account column holds an internal ID instead of the account name, ask how to translate it.
How do categorization rules survive a vendor exit?
Categorization rules survive a vendor exit only if you can export them as readable text: a match condition and a target account per rule. Learned coding, where the tool predicts accounts from history, rarely moves at all. What moves instead is the coded history itself, which a new tool can learn from again.
There are three cases to plan for:
- Exportable rules. The tool gives you a file of rules. You translate them into the new tool's format and test them on one month.
- Visible but not exportable rules. You can see the rules on screen but not download them. Copy them into a spreadsheet before you cancel.
- Learned patterns only. The tool has no explicit rules. Export at least twelve months of coded transactions so the next tool has the same examples to learn from.
The difference between explicit rules and learned coding affects more than portability. The guide to transaction categorization software compares the two approaches, including how easy each one is to check and correct.
Keep a master rule list outside any tool
Some practices keep a plain spreadsheet of each client's key vendor rules, outside every tool. It takes a few minutes per client to update after each close. It also makes any future switch a translation job rather than an archaeology job, and gives a new staff member a quick map of how the client is coded.
Data portability questions to ask before signing up
Ask about data portability before you sign up, while the vendor still wants your business. Get the answers in writing, ideally in the contract or the published help pages. Five questions cover most of what matters: what can be exported, in which format, how often, at what cost, and what happens to your data after you leave.
Use these questions in any sales call or trial:
- Can I export all original documents in bulk, sorted by client?
- Can I export transactions, rules and account mappings as CSV?
- Is there a fee, a limit or a waiting period for a full export?
- After I cancel, how long can I still log in and export?
- When is my data deleted, and can I get a confirmation?
Newer vendors deserve the same questions, asked with a little more care. A tool still in early access may not have built every export yet. The guide to weighing early access bookkeeping software covers how to use a young product while protecting yourself if it changes course. The wider bookkeeping automation software scorecard is a good place to add portability as a scored line, so it sits next to features and price rather than being an afterthought.
Portability gaps that surface only on the way out
The worst portability gaps surface only on the way out, when you try to leave a bookkeeping vendor and the export is missing something you assumed was there. Common gaps are original documents that cannot be bulk downloaded, rules that cannot be exported, history capped at a few months and accounts identified by internal codes instead of names.
Gaps worth checking for before you depend on a tool:
- Exports limited by date. Only the last 90 days can be exported at once, so a year takes many separate exports.
- Per-client exports only. Fifty clients mean fifty manual exports.
- Lost links between files and lines. Transactions export, but nothing says which statement each line came from.
- No review trail. The record of who approved which line stays behind.
- Access ends at cancellation. The login stops working on the day you cancel, before you finish exporting.
Each of these is easy to check during a trial and hard to fix later. Spend twenty minutes trying a full export for one client before you commit.
A worked exit for one client
Picture an example client with two bank accounts, eighteen months of history and forty vendor rules. A clean exit from the old tool would produce, at a minimum, these files: one folder of thirty-six original statement PDFs, one transaction CSV covering all eighteen months, one rules CSV with forty rows, and one account mapping sheet. If any of the four is missing, write down what it would cost to rebuild. Missing PDFs cost a request to the client or a trip to the bank portal. Missing rules cost a month or two of extra review while the new tool relearns them. Missing history costs the most, because the new tool then has nothing to learn from and every vendor looks new.
An edge case: client-owned subscriptions
Sometimes the client pays for the tool and you work inside their account. When the engagement ends, the data stays with the client, which is correct. Make sure your own working papers, notes and rule lists live somewhere you control, so you are not left without the record of your own work.
A yearly data portability drill for your bookkeeping tools
A data portability drill is a yearly test where you export one client's full record from each bookkeeping tool and confirm you could rebuild that client elsewhere. It takes an hour or two. It catches export features that broke, formats that changed and gaps that crept in as the vendor updated the product.
Run the drill with this checklist:
- Pick one active client with at least twelve months of history.
- Export every original document and count them against your own records.
- Export transactions and confirm the columns include date, description, amount and account.
- Export rules and account mappings, and open them in a spreadsheet.
- Check that account names, not internal codes, appear in the export.
- Store the exports with the date of the drill.
- Note anything missing and raise it with the vendor.
Statement conversion is where much of a practice's know-how builds up, so it deserves the same drill as the ledger. The overview of what bank statement automation can take over for a practice shows each step that produces data worth keeping. AutoBankConvert keeps each client's accounts, rules and history in a separate workspace, so a drill can stay one client at a time; ask what it exports before you rely on it, as you would with any tool.