Exporting SQL Account & AutoCount Ledgers: Step-by-Step Migration to Cloud SaaS

What should you export from SQL Account or AutoCount first?

Export enough evidence to reconstruct both balances and their supporting detail. A trial balance alone can prove account totals, but it cannot reproduce individual invoices, payments, journal descriptions, customer balances, or an audit trail.

Create a read-only source archive before cleaning any spreadsheet. Depending on the modules your business used, collect:

1. the chart of accounts, including code, name, type, parent or grouping, and active status;
2. a final trial balance for every financial year in scope;
3. detailed general-ledger activity with date, document reference, description, account, debit, and credit;
4. customer and supplier master files;
5. open receivables and open payables, including document dates, due dates, original amounts, payments, and outstanding amounts;
6. bank and cash-book detail plus the matching bank statements;
7. sales, purchases, credit notes, receipts, payment vouchers, and manual journals;
8. inventory and fixed-asset schedules if those balances will enter the target ledger; and
9. PDFs, attachments, tax reports, and audit reports required as supporting evidence.

SQL Account's published material confirms general-ledger and trial-balance reporting and also documents an XML export utility for master files and transactions. AutoCount's published cloud help confirms that a generated trial balance can be exported. Edition, version, access rights, and customized report layouts can change the available controls, so ask the source system to produce the accounting output above rather than following an invented click path.

Export	Minimum control to record	Why it matters
Chart of accounts	Account count and unique source codes	Drives the mapping table
Trial balance	Total debit, total credit, and difference	Governs the ledger tie-out
General ledger	Row count, date range, and debit/credit totals	Supports transaction-level reconstruction
Receivables	Document count and outstanding total	Must tie to the receivables control account
Payables	Document count and outstanding total	Must tie to the payables control account
Bank detail	Opening, movement, and closing balance	Must tie to external bank statements
Documents	Count and gross value by document type	Preserves operational and tax evidence

Keep raw, working, and evidence copies separate. Never edit the raw export; store controls, exceptions, and sign-off with the evidence.

Should you migrate full history or opening balances?

Decide the accounting boundary before transforming rows.

Method	What enters GetPay	Best fit
Full historical rebuild	Approved historical journals and supporting master or document data	GetPay must become the transaction-level ledger for prior years
Opening-balance cutover	A controlled brought-forward position, then new activity from the cutover date	The desktop system remains the historical archive
Hybrid by period	Full detail for the open financial year and opening balances for earlier closed years	The team needs current-year drilldown without rebuilding every closed year

The methods may differ by period, but they must not overlap. If a historical sale is rebuilt as:

Dr Accounts Receivable
  Cr Sales Revenue
  Cr Tax Payable, where applicable

and its unpaid amount is also included in the opening receivables balance, Accounts Receivable is duplicated. The same problem occurs when bank movements are imported and the resulting closing bank balance is loaded again as though the movements were absent.

Choose a cutover timestamp and write it into the control workbook. Entries up to that timestamp belong to the source authority; entries after it belong to GetPay. During the final export, freeze or tightly control source posting so the migration team is not reconciling against a moving target.

How do you map desktop account codes into GetPay?

Map economic meaning, not spreadsheet position or a familiar-looking number.

GetPay's chart importer accepts an approved four-digit target code, a name, and one account_type: ASSET, LIABILITY, EQUITY, INCOME, or EXPENSE. Account code and type are immutable after creation. The importer also retains source_code, source_name, source_type, and source_parent_code; parent_code is the approved target parent. A missing parent, malformed target code, or unknown target type is rejected rather than guessed.

Your mapping workbook should contain:

Mapping field	Decision
source_code and source_name	Preserve exactly as exported
source_type and parent	Record the desktop hierarchy and normal balance
target_code and target_name	Choose an approved four-digit GetPay account
target_type	Assign one permitted GetPay account type
treatment	Migrate detail, bring forward, archive only, or split
sign_rule	State whether source values need debit/credit normalization
review_status	Approved, exception, or unresolved

Never truncate a longer source code or silently reuse a convenient target account. Create an explicit target code and retain the source code in the map. Document and prove every many-to-one roll-up. Split a mixed source account only with an evidence-based rule.

Check control accounts carefully. Customer balances should reconcile to Accounts Receivable, supplier balances to Accounts Payable, bank accounts to external statements, and accumulated profit to the approved equity treatment. A balanced but badly mapped trial balance can still produce a wrong balance sheet.

What can GetPay accept during this migration?

Use the migration surface for the four reviewed CSV shapes it actually supports. Each batch is limited to 500 rows so the server can return the full per-row preview. Parsing happens in the browser; the server receives structured rows, runs the identical planner for preview and commit, and binds confirmation to that exact plan with a content fingerprint.

• Customers: name plus optional email, phone, tin, registration, address fields, and notes.
• Suppliers: name plus optional email, tin, registration, address fields, default_gl_account, and notes.
• Chart of accounts: approved target code, name, account_type, and optional target parent_code, with source mapping in source_code, source_name, source_type, and source_parent_code. The mapping-workbook aliases target_code, target_name, and target_type are accepted.
• Open receivables: document_number, customer_name, ISO document_date, ISO due_date, tenant currency, original_amount, paid_amount, outstanding_amount, explicit outstanding tax_amount, tax_type (exempt, sales, or service), and an approved INCOME gl_account.
• Open payables: document_number, vendor_name, ISO document_date, ISO due_date, tenant currency, original_amount, paid_amount, outstanding_amount, explicit outstanding tax_amount, and either one approved ASSET/EXPENSE gl_account or a reviewed GL on every supplied line.

Open-document CSVs may carry line_items as JSON. Receivable items are {description, amount}; payable items are {description, amount, gl_account}. Each item amount is its remaining net outstanding portion, not the source document's original line amount. When no item breakdown exists, GetPay creates one clearly labelled migration line from the reviewed net outstanding amount. The items must reconcile exactly to outstanding_amount - tax_amount.

The live invoice or bill total is the still-outstanding amount, so aging and later payment allocation work against the amount genuinely due. GetPay separately preserves the source original and paid totals. For POSTED books, the importer creates the outstanding AR/AP journal at the approved cutover date; the historical document date remains on the invoice or bill for aging. For VIRTUAL books, it creates the operational document without a real journal entry.

The following existing surfaces remain separate:

• Generic customer intake still accepts its existing batches of up to 1,000 rows; the migration page does not change that route or its callers.
• Opening balances are saved by fy, glAccount, debit, credit, and optional notes. The route requires an active target account and non-negative values; the editor displays total debit, total credit, and the difference.
• A journal draft uses je_date, description, and at least two lines. Each line carries account_code, debit, credit, and memo; exactly one side must be positive. Total debit and credit are compared at sen precision.
• Posting a draft journal is a separate admin action. It rechecks balance, refuses a closed period, and locks the accounting effect into the ledger.
• Bank-statement ingestion is a bank-specific workflow, not a substitute for a general historical-ledger importer.
• The Trial Balance page can export Code, Account, Type, Debit (RM), Credit (RM), Net (RM), and #Txns for reconciliation.

Do not rename an arbitrary desktop ledger CSV and assume GetPay will infer its meaning. The importer handles the five explicit modes above (open AR and open AP are separate operational modes), not a general-ledger rebuild. For full historical migration, use a reviewed transformation and authorized journal-loading process; for a balance-only cutover, use the applicable opening-balance or balanced-journal workflow for the tenant's ledger configuration.

What is the step-by-step migration sequence?

Use this order so parent records and accounting controls exist before dependent rows:

1. Scope the archive. List every company file, branch, currency, module, financial year, and attachment repository.
2. Freeze and export. Record the final source timestamp and preserve untouched exports, reports, backups, and document files.
3. Build controls. Capture row counts, unique references, date ranges, debit totals, credit totals, document values, and checksums.
4. Choose the accounting boundary. Approve full history, opening balances, or a period-based hybrid.
5. Approve the account map. Resolve every source code before loading money. Exceptions remain blocked.
6. Preview and create target master data. In Desktop Migration, load the approved chart first, then customers and suppliers. Review the full server preview and explicitly confirm each exact batch.
7. Load accounting values. Post approved historical journals or the cutover balance, never both for the same effect.
8. Preview and load open operational items. Import each still-outstanding invoice and bill by source reference, date, due date, party, tax, mapped account, and reconciled amount. Explicitly confirm the server preview, and do not also post the same AR/AP effect through opening balances or historical journals.
9. Reconcile banks. Tie software balances to statements at the same timestamp and investigate uncleared items separately.
10. Run the full tie-out. Compare the source and target trial balances by mapped account and verify supporting schedules.
11. Test the new workflow. Create, approve, post, report, and reverse representative transactions before daily entry begins.
12. Sign off and cut over. Make GetPay authoritative for new work and keep the desktop archive read-only for the agreed retention period.

Every batch should report inserted, skipped, rejected, and duplicate counts. Unmapped accounts, ambiguous customers, missing parents, invalid dates, and unbalanced journals belong in an exception file, never an invented suspense account.

How should opening balances be prepared?

Start from the final approved source trial balance at the chosen boundary. Normalize every account onto one side and map it before entering values.

A balance-sheet cutover commonly resembles:

Dr Bank and cash
Dr Accounts Receivable
Dr Inventory, deposits, and fixed assets
  Cr Accounts Payable
  Cr Loans and tax liabilities
  Cr Capital and retained earnings

The exact lines depend on the source books. Do not invent a balancing account, tax amount, or retained-earnings figure. If debits and credits do not match, trace the difference to a missing account, sign inversion, omitted subledger, foreign-currency treatment, or incomplete year-end close.

GetPay's opening-balance editor saves rows independently and displays the running debit, credit, and difference totals. Treat a zero difference as a mandatory sign-off condition; a visible warning is not a substitute for accounting review. Confirm the tenant's ledger configuration before choosing between the opening-balance editor and a posted opening journal.

For a mid-year cutover, agree whether the target receives a beginning-of-year opening position plus current-year transaction detail, or a cutover-date position with earlier detail retained only in the old system. Mixing those approaches duplicates current-year profit or loss.

How do you verify the trial-balance tie-out?

Verification must compare values, not only row counts.

1. Export the final source trial balance and the target GetPay trial balance for the same financial year, cutover date, and accounting basis.
2. Join them through the approved source-to-target mapping.
3. Compare each target account's debit, credit, and net balance.
4. Confirm source total debit equals source total credit, target total debit equals target total credit, and the target difference is RM0.00.
5. Tie Accounts Receivable to the open-customer schedule and Accounts Payable to the open-supplier schedule.
6. Tie every bank and cash balance to independent statements or cash evidence.
7. Reconcile retained earnings and current-year profit or loss across the cutover boundary.
8. Sample early, middle, and late records plus unusual, high-value, tax, partial-payment, credit-note, and foreign-currency cases.

For each sample, compare reference, date, party, description, debit, credit, tax treatment, amount, and linkage. A perfect trial balance can coexist with corrupted descriptions, swapped customers, or offsetting duplicates.

Also run negative controls: no unresolved map rows, no target postings after the source freeze but before authorization, no duplicate source references, no orphan payments, no inactive target accounts, no journals left unintentionally in DRAFT, and no amounts loaded through both history and opening balances.

When is it safe to retire the desktop books?

Retire daily entry only after the raw archive is complete, all exceptions have owners, the mapped trial balance ties, subledgers tie to control accounts, banks tie to statements, and staff have tested the new approval and reporting workflow.

Keep SQL Account or AutoCount read-only during an assurance period if access permits. Store exports, backups, attachments, mapping, reconciliation evidence, and sign-off independently. Confirm record-retention requirements with your accountant and the relevant authority's published guidance. Find a Malaysian accounting or bookkeeping provider in the GetPay directory if you need independent migration and tie-out support.

The migration is complete when the authority boundary is unambiguous: the desktop system explains history up to the cutover, and GetPay is the only place where new accounting activity is recorded after it.