Bringing a client's ledger across, step by step

How a firm moves a client's ledger into Achekam in named steps, who approves the differences found on the way, and how a migration is rolled back.

By Achekam · 11 October 2026 · 5 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya

A new client arrives with years of history in another accounting package, and somebody has to get that ledger across. Most firms have a story about the time it went wrong: an opening trial balance that did not agree to the signed statements, a suspense account nobody could account for, and a quiet "balancing" journal that a reviewer found months later.

The technical part of a migration is rarely the hard part. The hard part is deciding who may accept a difference, and being able to show afterwards why it was accepted. This article walks through how a ledger is brought into Achekam, where the controls sit, and what a manager should check before the client's books go live.

Two ways in, and one that is not ready

A firm can bring a client's ledger into Achekam in two ways. The first is from files the client exports from its current package, as CSV or Excel. The second applies when the client already keeps its books on Achekam: the firm reads the opening figures from those books directly. Both start from the Migration Centre under Settings, shown as "Move to Achekam".

You will also see connections listed for Xero, Sage Business Cloud and Sage 50 / Pastel. Treat them as not available for now: none of them works until the app registrations it depends on are in place. Plan your timetable around exported files, and ask the client for them early.

One limit matters for firms in Nigeria and Kenya. The ledger screens show every amount in rand, and the chart of accounts is stored in ZAR, even for a Nigerian or Kenyan business. Before migrating a client whose books are kept in naira or shillings, agree internally how the team will read and present those balances, and record that decision on the engagement.

The route from source to cut-over

A migration in Achekam runs through named steps, in this order:

1. Connect the source.
2. Choose the company.
3. Choose the periods and how much detail to bring.
4. Analyse what was received.
5. Map the accounts.
6. Reconcile.
7. Preview.
8. Import.
9. Verify.
10. Cut over.

The value of named steps is that everyone on the job knows where the migration stands. A senior who asks "where are we on the new client?" gets an answer such as "reconciling, two differences open" rather than "nearly done". It also gives the reviewer obvious points at which to look: after mapping, after reconciling, and before cut-over.

If you are only preparing annual financial statements from a general ledger export, you may not need a full migration at all. Achekam can add up an uploaded general ledger into a trial balance and check every printed account total against its own sum, which is covered in turning a general ledger into a trial balance.

Mapping that remembers

Mapping is where most of the staff time goes on a first migration. Achekam remembers earlier mapping decisions and asks only about accounts that are new or have changed. Where it has guessed an account's class, the guess is labelled as a guess.

Give those labelled guesses to your most experienced person on the job. A guessed class on a loan account, a deposit or a related-party balance can move a figure between current and non-current, and that error follows the client into every set of statements you prepare afterwards. The approval side of mapping is set out in more detail in how trial balance mapping suggestions are approved.

Differences need someone independent

When a difference is found during a migration, it has to be explained, and then approved by someone who is neither the preparer nor the person who wrote the explanation. Where the preparer and the person who explains are different people, three people touch every accepted difference; even where they are the same, the approval always comes from someone else.

A worked example in words: the old package's debtors control account does not agree to its own age analysis. The clerk who prepared the migration finds a credit note posted after the export was taken. A senior writes that up as the explanation, with the credit note attached on the file. The manager, who did neither, reads the explanation, checks the credit note and approves the difference. If the manager is not satisfied, the difference stays open and the migration does not move on as if it were settled.

This is stricter than many firms' habits, and deliberately so. A difference accepted by the person who found it is the textbook way for an error to become an opening balance. The principle is segregation of duties, which AccountingTools explains as giving the steps in a process to different people so that no one can both commit and conceal an error.

For a business moving its own books into Achekam the same discipline applies in a slightly different form: the move reconciles to the cent before a second person approves the cut-over.

Rolling back when something is wrong

A migration can be rolled back, and the person doing it must give a reason. Use it without embarrassment. The usual triggers are the wrong company chosen at the start, the wrong periods brought in, or an export the client later admits was taken before a month-end adjustment. Rolling back with the reason written down is better than layering correcting journals on top of a bad import.

Once the books are live, new journals proposed from documents, bank lines or adjustments are only candidates, and a person approves and posts each one. That workflow is described in posting candidates a person approves.

Before you press cut-over

A short checklist for the manager who signs off the migration:

• The cut-over date is agreed with the client in writing.
• You hold the last signed financial statements and the old package's closing trial balance for the same date.
• Every account flagged as a guessed class has been looked at by a senior.
• Every difference has an explanation and an approval by someone who neither prepared nor explained it, and none is still open.
• The verified opening trial balance agrees to the signed statements, or the reconciling items are explained.
• For a Nigerian or Kenyan client, the team's decision on presenting rand-denominated ledger screens is recorded.
• The client knows which date is the last one entered in the old package.

Next step

Before the next new client arrives, decide who in your firm can approve migration differences and write it into your onboarding procedure. Then ask the client for its exports, its last signed statements and its closing trial balance in the same request, so the reconciliation can start on the day the files land.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.