Migrating your accounting software to the cloud: balance transfer

Quick answer. An accounting software migration succeeds when the balance transfer is clean, not when the tool looks nice. The method has five steps: choose a switch date, ideally at the start of a financial year; export the data and the accounting entries file (FEC) from the old tool; carry over the opening balance and opening entries exhaustively, item by item on the sub-ledgers; check balances to the euro; archive the old system, bearing in mind that the accounting conservation duty runs up to ten years (Commercial Code art. L123-22).

Changing accounting software, usually to move to the cloud, has become routine. It nonetheless stays risky as soon as the data transfer is treated as a technical detail. A poorly carried-over balance is invisible on switch day: it surfaces at the close, as unexplained discrepancies, customer balances that cannot be matched, and a balance sheet that does not add up. The difficulty is not configuring the home screen, it is the accounting fidelity of what enters the new system.

Two obligations frame the operation and never disappear with the old software: the requirement to present accounting documents as an accounting entries file when bookkeeping is computerised (Tax Procedure Code art. L47 A) and the conservation of accounting books and records (Commercial Code art. L123-22). On the retention period, two regimes coexist and you should keep the more demanding one: commercial law requires ten years (art. L123-22), while tax law requires at least six years for audit purposes (Tax Procedure Code art. L102 B). Everything else is a matter of method.

The switch date alone decides the complexity of the project. The ideal moment is the first day of a financial year: the closing balance of the previous year mechanically becomes the opening balance of the new software. The transfer is then limited to balance-sheet figures, readable and fixed.

A mid-year switch is technically possible, but it changes in nature: you must carry over not only the opening balance-sheet figures but also the entire movement of the elapsed period (purchases, sales, bank, payroll, VAT). The volume of entries to re-inject or re-key explodes, and with it the risk of discrepancy. That is why we advise against a mid-year switch, except under strong constraints (end of the vendor's contract, acquisition, loss of access).

The table below sums up the trade-off we systematically set before any costing.

Planning the migration in line with the accounting calendar, not the vendor contract date, is therefore the first decision, even before choosing the tool. In practice, we set the switch on the already-validated close: as long as the previous year is not definitively closed and filed, the opening balance of the new tool may still move, and any early transfer will have to be redone a second time.

The heart of the migration is the faithful transfer of the data. Before closing access to the old system, you must extract everything that cannot be rebuilt afterwards. An incomplete export is rarely recoverable once the subscription is cancelled.

The items to retrieve go beyond the trial balance. The minimum list includes the general and sub-ledger closing balances, the ledger, the entry journals, the accounting entries file in the regulatory format (Tax Procedure Code art. L47 A), the fixed-assets and depreciation schedule, and the VAT statements. The FEC is a standardised text file (encoded in UTF-8, most often pipe-delimited) that lists every entry of the year with standardised fields: journal, date, account number, label, debit, credit, document reference. It is this format, and only this one, that is enforceable against the tax authority. To this add the structuring items often forgotten: the company's chart of accounts, customer and supplier records, saved bank details, invoice templates and bank reconciliations in progress.

A partial transfer is paid for at the close, when discrepancies appear and the old system must be reopened. That is exactly the scenario a structured backup avoids: applying the 3-2-1 rule to your accounting data before the switch protects the old data set throughout the checking phase. This discipline meets the duties of enforceable archiving of accounting records: an export only has value if it is kept in a readable and tamper-proof form.

Opening entries are the entries that carry the balance-sheet account balances from one year to the next. In a migration, they serve to re-enter into the new tool the company's exact position at the switch date. The rule is exhaustiveness: every balance-sheet account, not only the main ones.

Two traps recur. The first is to carry over customer and supplier accounts as a single global balance instead of carrying over each open item one by one. Matching then becomes impossible, reminders are distorted, and the sub-ledger no longer reconciles with the general balance. The second is to neglect fixed assets: you must carry over the gross value, the depreciation already recorded and the residual useful life, failing which future charges will be wrong and the tax return inconsistent.

Carrying over sub-ledgers item by item: an example#

Take a customer control account (411) showing a balance-sheet figure of 18,000 euros at the switch date. The temptation is to post a single opening entry of 18,000 euros to a generic customer account. This is the most frequent cause of migrations going off the rails.

The right method is to carry over, for each customer, the detail of the still-open invoices: invoice F-2025-114 of 7,200 euros on customer A, invoice F-2025-131 of 4,800 euros and credit note CN-2025-009 of 600 euros on customer B, invoice F-2025-142 of 6,600 euros on customer C. Each item is entered individually, with its date, reference and due date. The sum of the individual balances (7,200 + 4,200 + 6,600) must equal the control balance of 18,000 euros. The same principle applies to suppliers (account 401).

The point is not theoretical. An item-by-item transfer lets you match future receipts correctly, chase the right customer on the right invoice, and instantly trace the origin of a balance during the review. A bulk transfer makes all this impossible: the first partial receipt leaves an orphan balance that no reminder can explain.

Income-statement accounts, by contrast, are not carried over as opening entries: they start from zero at opening. This is a classic source of error for non-specialists who believe they must re-inject everything.

Moving to the cloud shifts part of your accounting data, and often personal data, to a third-party host. This dimension is too often handled as an afterthought, although it conditions the compliance of the whole. Migrating suspends neither the GDPR nor business confidentiality: the data controller remains the company, not the vendor.

Four points deserve a written check before signing.

• Data residency. Where are the servers hosted? Hosting in the European Union simplifies GDPR compliance and avoids questions of transfer outside the EU. If the vendor is non-European, you must check the legal framework of the transfer (standard contractual clauses, adequacy decision).
• Encryption. Data must be encrypted in transit (secure connection) and at rest (on the servers). This is the minimum protection against unauthorised access.
• Vendor guarantees. A recognised certification (SOC 2, ISO 27001, certified health-data host for the relevant professions) attests to an audited level of control. Failing that, ask for the security audit report and the business-continuity plan.
• Audit trail and reversibility. The contract must guarantee an audit trail (who accessed what, and when) and above all a reversibility clause: the ability to export your data at any time in a usable format, FEC included, if you leave the vendor. Without reversibility, you endure the next migration instead of steering it.

Migrating personal data of customers or employees without this check exposes you to a risk that must be handled with the same rigour as professional secrecy and data pseudonymisation. The company's record of processing activities must be updated to reflect the new host and processor.

Two final steps secure the operation. The consistency check consists of reconciling each balance carried over into the new software with that of the old, to the euro. The opening balance must be balanced (total debit equal to total credit), the customer sub-ledger must equal the 411 control account, the supplier sub-ledger the 401 account, and the fixed-assets schedule must reconcile with the class-2 accounts. Any discrepancy, even of one euro, must be identified and corrected before posting the first entry of the year.

Resolving a discrepancy, step by step#

Suppose that, after transfer, the opening balance shows a debit of 124,350 euros and a credit of 124,280 euros: a discrepancy of 70 euros. Rather than forcing the balance with a difference entry (the worst response, because it hides the error), here is the approach we apply.

1. Isolate the class. We compare class by class (1 to 5) the carried-over total with that of the old balance. The discrepancy usually sits on a single class, which immediately narrows the search.
2. Drill down to the account. Within the identified class, we reconcile each account balance against the old balance. A fixed-assets account carried over at 12,430 instead of 12,500 betrays a 70-euro keying slip.
3. Check the sub-ledgers. If the discrepancy is on class 4, we compare the sum of the individual balances against the control balance: a forgotten credit note or an invoice entered twice surfaces immediately.
4. Correct at source, not by offset. We fix the wrong opening entry; we never create an adjustment entry to mask the discrepancy.

This protocol turns a blind hunt into a methodical check of a few minutes. As long as the opening balance is not balanced and each sub-ledger does not equal its control account, the first entry of the year must not be posted.

Archiving is then an obligation, not a comfort option. Books, registers and accounting records are kept for ten years under the Commercial Code (art. L123-22), and the tax retention period runs for at least six years for audit purposes (Tax Procedure Code art. L102 B): it is the longer period that should guide archiving. The migration purges nothing: in an audit covering a year kept in the old software, it is that old data set that will have to be presented.

Our view: the tool does not make the migration, the method does#

In the files we take over, the most common mistake is to have chosen the software on the sales demo and treated the data transfer as an import formality. The opposite should be done. The cloud brings real advantages, accessibility, automatic backups, continuous updates, real-time collaboration with the firm, but none of these corrects a wrong opening balance.

Three failure patterns keep coming back in the files we recover. The first: a switch launched mid-year to avoid waiting, with only the main balances carried over, which surfaces as a discrepancy of several thousand euros at the close. The second: an automatic "turnkey" import by the vendor, never checked to the euro, where a whole class slipped into the wrong account (expenses posted to fixed assets) without anyone noticing before the tax return. The third, more discreet: fixed assets carried over at net book value instead of gross value and accumulated depreciation, which makes the following years' charges impossible to justify and weakens any later tax audit.

We consider a careful migration to be invisible: accounting continues without a break, the next close reveals no discrepancy. A botched migration, on the other hand, is always discovered, and always at the worst moment, at the close, when time is short. When the switch comes with a tool featuring artificial-intelligence functions for data entry or reconciliation, we recommend framing their use from the outset, for example through an AI usage charter for the company, so as not to let automations decide accounting allocation on their own.

A services company contacts us after migrating on its own to cloud software mid-year, carrying over only the balances of the main balance-sheet accounts. At the close, the balance sheet does not add up: several thousand euros of discrepancy on the customer and supplier accounts, for lack of carrying over the open items one by one. Matching is unusable, and the fixed-assets schedule has lost its residual useful lives, which distorts the year's charges.

The correction required reopening the old system, fortunately still accessible because it had been backed up, rebuilding the sub-ledgers item by item, and re-establishing the fixed-assets schedule from the original values. For the migration of another entity in the same group the following year, the switch was planned for the first day of the financial year, with a complete transfer of opening entries and a reconciliation to the euro of the sub-ledgers against the control accounts: no discrepancy at the close. The initial extra cost of method was far below the time spent fixing the first file.

In practice: securing your migration#

• Lock the switch date at the start of the year first and put it in a calendar shared with the firm.
• Export and back up all the data before any cancellation: balance, ledger, FEC, fixed assets, sub-ledgers, VAT.
• Carry over the opening entries exhaustively, handling customers and suppliers item by item, never as a global balance.
• Check the provider's hosting (residency, encryption, certification, reversibility) before transferring any personal data.
• Check that the opening balance balances and that the sub-ledgers equal the control accounts before the first entry of the year.
• Keep the old data set and its FEC over the longest applicable period (up to ten years), on a medium separate from the new software.
• Document each step: a traced migration file serves as evidence in an audit.

A few pitfalls keep coming up in migrations run without framing, especially when they are left to the IT provider alone.

• Carrying over customer and supplier accounts as a global balance rather than item by item: matching and reminders become unmanageable.
• Forgetting fixed assets (gross value, accumulated depreciation, residual life): future charges and the tax return come out wrong.
• Confusing balance-sheet figures with income-statement accounts: only the former are carried over as opening entries.
• Cancelling the old subscription before exporting and verifying all the data, FEC included.
• Forcing the opening balance with a difference entry instead of looking for the cause of the discrepancy.
• Assuming the move to the cloud removes the archiving duty: the conservation obligation remains, on the old system's data, up to ten years under commercial law (art. L123-22).
• Migrating personal data (customers, employees) without checking the host's residency, encryption and security guarantees.

To make the whole thing reliable, it is better to have the switch framed by your chartered accountant in charge of tax, to anchor it in a bookkeeping and account review engagement that guarantees the final check of the balances, and, in a group environment, to check consistency with the structuring of a holding company when several entities share the same tool. Understanding the role of the chartered accountant in this kind of operation avoids reducing the migration to a purely IT matter.