HQ Wealth ↔ Sage Business Cloud Accounting: The Complete Journal Import & Export Guide
HQ Wealth is a full double-entry accounting platform for crypto and traditional wealth: real debits and credits, a nominal chart of accounts, wallet and exchange reconciliation, FIFO, LIFO, HIFO and AVCO cost basis, staking and liquidity positions, IFRS reports and tax packs. Sage Business Cloud Accounting is where a large share of UK, Irish and North American practices keep their statutory books. Getting figures from one to the other should be a journal post, not a week of spreadsheet surgery.
Because HQ Wealth already thinks in debits and credits, exporting to Sage is a natural fit — every journal entry in HQ Wealth is already balanced and already coded to a nominal account, which is exactly the shape Sage's journal importer wants. This guide covers both directions: how HQ Wealth writes Sage's exact journal CSV so it imports on the first attempt, and how HQ Wealth ingests a Sage export so a client's existing ledger flows back into a crypto-aware book. It is written for the accountant or bookkeeper who runs Sage and needs proper crypto cost basis sitting behind it, on either side of the Atlantic.
Exporting HQ Wealth → Sage
Sage's journal CSV importer expects a fixed 12-column layout with a header row that matches its documented field names, per Sage's import-journals help. Get the columns in the right order with the right headers and each journal balanced, and the file posts cleanly. HQ Wealth generates this file for you — you never build it by hand — but it helps to know exactly what comes out.
The UK and Ireland layout, column by column
For the UK and Ireland edition of Sage Business Cloud Accounting, the columns run A to L in this order:
| Position | Column | Mandatory? | Format / limit | Example | |---|---|---|---|---| | A | Reference | Yes | Up to 75 characters; groups the lines of one journal | STK-2026-03 | | B | Date | Yes | Numbers in day/month/year only | 29/12/2022 | | C | Description | No | Up to 200 characters | Staking rewards March 2026 | | D | Nominal Code | Yes | Must already exist in your Sage chart | 4900 | | E | Details | No | Up to 200 characters | ETH staking reward income | | F | Include on VAT / Tax Return? | No | Yes, Y, No or N | No | | G | Debit | Yes | Amount up to 99999999.00 | 1520.25 | | H | Credit | Yes | Amount up to 99999999.00 | 0.00 | | I | Analysis Type 1 | No | Up to 250 characters | Crypto | | J | Analysis Type 2 | No | Up to 250 characters | ETH | | K | Analysis Type 3 | No | Up to 250 characters | Wallet-A | | L | Exchange Rate | No | Foreign-currency journals only | 1.27 |
A few of Sage's own constraints are worth stating in full, because they are the difference between a clean post and a rejected file (all per the Sage help page):
- Dates are numeric day, then month, then year. Sage's wording: "Only numbers in day, month, and year format. For example, 29/12/2022." No month names, no ISO ordering.
- Debit and credit live in separate columns. Unlike Xero, which uses one signed amount column, Sage keeps Debit (G) and Credit (H) apart. Each amount "must be less than or equal to 99999999.00."
- Each journal must balance to zero. Total debits must equal total credits across the lines of a single journal.
The shared-Reference grouping rule
This is the mechanism that turns a flat CSV into multi-line journals, and it is the detail most hand-made files get wrong. Sage's rule, verbatim: "We create a new journal when the data in column A is different from the previous row." In other words, every line that belongs to the same journal must repeat the identical Reference in column A, on consecutive rows. The moment column A changes, Sage starts a new journal.
HQ Wealth handles this for you. Each HQ Wealth journal entry exports as a block of consecutive rows that all carry one shared Reference, with the entry's debit lines and credit lines listed underneath, and the block balances to zero before the next Reference begins. You do not have to sort, group or renumber anything — the exporter emits the rows already grouped and already balanced.
The VAT / tax-return flag in column F maps from how the underlying HQ Wealth line is treated: lines that should appear on a VAT or tax return export as Yes, everything else as No. And for a multi-currency journal, HQ Wealth populates the Exchange Rate in column L so Sage can translate the foreign amounts — that column stays blank for home-currency journals.
North American edition — the column-order trap
Here is the single biggest gotcha, and it has nothing to do with your data. The North American edition of Sage Business Cloud Accounting also uses 12 columns, A to L, and the same mandatory fields — but it puts them in a different order, and it expects month/day/year dates. Send a UK-ordered file to a North American Sage company (or the reverse) and every value lands in the wrong field.
The North American layout is:
| Position | Column | Notes | |---|---|---| | A | Reference | Same as UK | | B | Date | Month / day / year order | | C | Description | Same as UK | | D | Ledger Account Number | The nominal / account code | | E | Details | Same as UK | | F | Analysis Type 1 | Analysis moves up | | G | Analysis Type 2 | | | H | Analysis Type 3 | | | I | Include on Tax Return? | Yes / Y / No / N | | J | Debit | | | K | Credit | | | L | Exchange Rate | Foreign-currency journals only |
So on the North American side, the account code is labelled Ledger Account Number and sits in D, the three Analysis Types move up to F, G and H, the tax-return flag drops to I, and Debit and Credit shift to J and K. Dates flip to month/day/year.
HQ Wealth asks which regional edition your Sage company uses and emits the correct layout — UK/Ireland or North American — with the matching date order. You pick the region once; the exporter does the rest. If you ever move a file between two Sage companies in different regions, re-export rather than reshuffling columns by hand.
One thing HQ Wealth cannot invent: your chart of accounts
Every value in the Nominal Code column (UK/Ireland) or Ledger Account Number column (North America) must already exist in the target Sage company's chart of accounts. Sage will not create a missing account on import. Before your first export, map your HQ Wealth accounts to the Sage codes you actually use — for example, a crypto asset account, a realised-gain account and a staking-income account — and confirm each code is live in Sage. HQ Wealth lets you save that mapping so every future export is coded correctly with no rework.
Importing Sage → HQ Wealth
The other direction matters just as much: a client arrives already on Sage, and you want their existing ledger sitting behind crypto-aware cost basis. Sage Business Cloud Accounting can export its ledger data to CSV — a Nominal Activity report, a journals export, or a trial balance export — and HQ Wealth's importer reads that export and turns each line back into a proper double-entry posting.
The general structure of these Sage exports is a set of rows carrying a date, a nominal code or account name, a reference or description, and Debit and Credit amounts — the same debit/credit-per-code shape as the import format, confirmed against your specific Sage export at build time rather than assumed here. Sage's exact export headers vary by report and region, so HQ Wealth confirms the column mapping against your first real file rather than guessing at it.
Here is how our importer maps a Sage export into HQ Wealth. This describes our mapping, not a Sage-published spec:
| Sage export field | HQ Wealth target | |---|---| | Nominal Code / Ledger Account Number | Matched to the corresponding HQ Wealth nominal account | | Debit amount | Debit line on the HQ Wealth journal entry | | Credit amount | Credit line on the HQ Wealth journal entry | | Reference | Groups lines into one journal entry, mirroring Sage's own column-A rule | | Date | Parsed to the HQ Wealth entry date (region-aware day/month vs month/day) | | Description / Details | Carried onto the entry and its lines |
Because HQ Wealth is a true double-entry ledger, each grouped Reference becomes one balanced journal entry, and the importer checks that debits equal credits before anything posts. You review a mapping preview — every proposed account match and entry — before committing, and you can correct any account link line by line. Where a Sage nominal code has no HQ Wealth counterpart yet, the preview flags it so you can create or map the account rather than silently dropping the line.
Format quick reference
The two regional layouts side by side:
| Field | UK / Ireland position | North American position | |---|---|---| | Reference | A | A | | Date | B (day/month/year) | B (month/day/year) | | Description | C | C | | Account code | D (Nominal Code) | D (Ledger Account Number) | | Details | E | E | | Analysis Types 1 to 3 | I, J, K | F, G, H | | Tax-return flag | F | I | | Debit | G | J | | Credit | H | K | | Exchange Rate | L | L |
And the rejection causes we see most, with the fix:
| Symptom | Cause | Fix | |---|---|---| | Values land in the wrong fields | UK file sent to a North American Sage company, or the reverse | Export for the correct region so the column order and date order match | | Journal will not post | Debits do not equal credits within one Reference | Balance each journal to zero before import | | Lines split into separate journals | Column A Reference not repeated on every line of the entry | Keep an identical Reference on consecutive rows of one journal | | Amount rejected | A Debit or Credit above 99999999.00 | Split the posting so each amount stays at or below the cap | | Line rejected | Nominal code / Ledger Account Number not in the Sage chart | Create or map the account in Sage first | | Dates misread | Day/month/year used in a North American company, or the reverse | Match the date order to the region: day/month/year for UK/Ireland, month/day/year for North America |
FAQ
What is the Sage Business Cloud Accounting journal import CSV format? A fixed 12-column layout, A to L, with a header row matching Sage's documented field names. In the UK and Ireland edition the order is Reference, Date, Description, Nominal Code, Details, VAT/tax flag, Debit, Credit, three Analysis Types, then Exchange Rate. Each journal must balance, and amounts cap at 99999999.00, per Sage's help page.
Why did Sage split my journal into several separate journals? Sage starts a new journal whenever column A, the Reference, differs from the previous row. If the lines of one journal do not share an identical Reference on consecutive rows, each line becomes its own journal. HQ Wealth groups every entry under one shared Reference so this cannot happen.
Does the Sage journal CSV differ between the UK and North America? Yes, and it is the most common cause of a broken import. Both editions use 12 columns and the same mandatory fields, but North America reorders them — Ledger Account Number in D, Analysis Types in F to H, the tax flag in I, Debit and Credit in J and K — and expects month/day/year dates. HQ Wealth emits the layout for whichever region your Sage company uses.
Do my nominal codes have to exist in Sage before I import? Yes. Sage will not create accounts on import, so every Nominal Code (UK/Ireland) or Ledger Account Number (North America) must already exist in the target chart of accounts. Map your HQ Wealth accounts to live Sage codes once, and every future export is coded correctly.
---
Ready to run crypto cost basis behind your statutory Sage books? Try HQ Wealth and post balanced journals straight into Sage — in the right regional format, first time.