Most organisations arrive with history. The import surface brings it in from a spreadsheet, one entity at a time.
What can be imported
Eight things: the chart of accounts, customers, vendors, items, invoices, bills and expenses, payments, and journal entries.
The order matters
This is the single most important thing on this page, because importing out of order means importing twice.
Chart of accounts first. Everything posts into it, and nothing else can be mapped without it.
Then customers, vendors and items. The things transactions refer to.
Then invoices and bills. These reference customers, vendors and accounts, all of which now exist.
Then payments, which reference invoices.
Then journal entries, including opening balances.
Each step depends on the ones before it. An invoice imported before its customer either fails or creates a duplicate customer, and cleaning that up afterwards is worse than doing it in order.
How an import runs
Four phases, and each is a chance to stop before anything is written.
Upload. A spreadsheet or CSV, parsed for its headers and rows.
Mapping. Each column is matched to a field, with sensible suggestions from the header names. Anything required and unmapped blocks you from continuing, which is the guard that prevents a half-mapped import.
Preview. A handful of transformed rows, so a wrong mapping is visible before it is applied rather than afterwards.
Resolve. References are matched against what already exists: this invoice's customer, this line's account. Anything unmatched is surfaced so you can decide rather than having the import guess.
That resolve step is the one that makes an import trustworthy. A row referring to a customer that does not exist is a decision, not an error to be silently absorbed.
Where the data comes from
Every accounting package exports to a spreadsheet, and that export is the input here.
Export per entity rather than one combined report. Most packages offer exactly the eight shapes this imports.
Export at a period boundary. Bringing in a part-month means reconciling a partial period, which is avoidable by waiting for the month end.
Keep the original files. They are the only record of what was migrated if a figure is ever questioned, and they cost nothing to keep.
Preparing the spreadsheet
One entity per file. A workbook containing everything is convenient to export and impossible to import cleanly.
Headers on the first row, named recognisably. The mapping suggests matches from them, so "Account Code" is matched and "col_3" is not.
Consistent references. If invoices refer to customers by name, every name must match exactly. A trailing space is a different customer.
Dates in one format throughout.
Amounts as numbers. Currency symbols, thousands separators and text in a number column are the most common cause of a failed row.
Do a small one first
Ten rows, then check what arrived.
It takes five minutes and it catches the mapping mistakes that are invisible in a preview and obvious in the result. Importing four thousand rows and discovering the date format was wrong is a considerably worse afternoon.
Opening balances
Where you are moving mid-year, the opening position comes in as journal entries.
Get these from your accountant. An opening balance assembled by inference from a previous system is the most likely source of a trial balance that never quite balances, and it is very hard to unpick later.
Post them dated to the day before you start, so your first period in the platform is clean.
Reference resolution
The resolve phase is where an import becomes trustworthy, and it is worth understanding what it does.
Every reference in the file, a customer name on an invoice or an account code on a line, is matched against what already exists. Matches are linked; anything unmatched is listed for you to decide about.
Nothing is invented. An unmatched customer does not become a new blank customer silently, which is how most spreadsheet imports produce a duplicate directory.
Unmatched usually means a naming difference, not a missing record. A trailing space, an abbreviation, a legal name against a trading name. Fixing the source file is almost always better than creating a second record.
After importing
Run the trial balance. It has to balance. If it does not, the problem is in the import and it is far easier to fix now than after a month of trading on top of it.
Check a few records by hand against the source. Three invoices and two customers is enough to confirm the mapping was right.
Run the reconciliation, which is the fastest check that receivables and the ledger agree.
Historical detail
A decision worth making before you start: how much history to bring.
The current fiscal year is the usual answer, plus opening balances for everything before it. It gives comparable periods within the year without importing a decade.
Everything is rarely worth it. Older data is less reliable, took a different shape, and will be consulted approximately never.
Nothing but opening balances is legitimate for a small organisation, and it means no comparative figures in the first year.
Doing it in the right order, again
It bears repeating because it is the mistake that costs a day.
Chart of accounts, then the things transactions refer to, then the transactions, then payments, then journals. Every step depends on the ones before, and the resolve phase will tell you when something is missing rather than inventing it.
Importing from QuickBooks directly
You do not have to export QuickBooks to a spreadsheet. There is a direct import.
Connect the QuickBooks account, and the import previews what is there by fetching a count per entity before anything is written. You then choose which entities to bring, and it imports them in dependency order: chart of accounts, customers, vendors, items, invoices, bills, payments, journal entries.
It reports per entity what was inserted, updated, skipped and errored, and each run is recorded in a sync history so there is an audit trail of what was brought in and when.
Dependencies are surfaced rather than assumed. Invoices need customers first, and the picker says so, which is the same ordering the spreadsheet route requires and here it is enforced for you.
It is an import, not a two-way sync
Data moves from QuickBooks into NearSync. Nothing is pushed back, and nothing runs continuously.
That distinction matters for planning a migration. This is the tool for moving your books across once, and possibly for topping up during a parallel-run period. It is not a mechanism for keeping two systems in step indefinitely, and running both as systems of record is a bad idea regardless of tooling.
Importing from Stripe
The same worker imports from Stripe: customers, products and invoices.
Subscriptions and payments are recognised in the picker and not yet transformed, and the result panel says so per entity rather than failing silently.
What is not supported
Bank feeds. Transactions are not pulled from a bank.
Attachments. Documents attached to records in a previous system do not come across with the data.
Continuous synchronisation with any accounting package. Imports are runs you start, not a background process.
Did this answer your question?
No, ask a person