How SKU.io reconciles with Xero and QuickBooks

Several rows in the Sync & reconciliation section of the close checklist, one in Sign-off, and three of the nine reports in the report pack are about your accounting provider. This page explains what each of them compares, where the figures come from, and what the close won't do on your behalf. It applies to a first close and to a re-sign-off alike.

What the close reads, and the one thing it fetches

Almost every check and report is built from records SKU.io already holds: its own ledger, its local copy of your provider's documents, and the provider lock dates it imported earlier.

The exception is your provider's trial balance as at the month end, which the Trial balance reconciled to provider check needs fresh. SKU.io fetches it for you when you click Start close, on every Re-check while the month is in review, and when you re-sign-off a restated month. Capture provider balances, at the top of the Report pack, fetches it again on demand. See Capture your provider's trial balance.

Two things follow:

• An unreachable provider fails that one check, not the close. If Xero or QuickBooks can't be reached, or the connection needs reconnecting, Trial balance reconciled to provider fails with the provider's reason. Whether that stops the close depends on one setting; see Trial Balance Reconciliation. Nothing else in the close waits on your provider.
• The rest of the evidence can be stale. The other checks compare against whatever was last brought across. If the local copy of your provider's documents stopped refreshing three weeks ago, the reconciliation rows say so rather than show agreement. See when the local copy does not cover the month.

Reconciled here is not the same as pushed there

The close reconciles. It never posts, corrects or locks anything inside Xero or QuickBooks. Everything it writes, it writes in SKU.io.

Entries still on their way to your provider

Entries synced, in Sync & reconciliation, counts entries dated inside the month that have not finished their trip to the provider — queued, mid-sync, retrying after a transient error, or holding an update that has not landed yet. The row reads, for example, 4 still in flight, and its arrow opens exactly those entries.

This is a warning, not a blocker, so a month can close over it. What it costs you is worth being clear about: a month closed with entries in flight will diverge from your provider the moment the backlog drains. The provider's June total moves after you have already signed off SKU.io's June total as the number of record.

The check's own tooltip draws the boundary that most often gets confused:

No entries dated in the period are still pending, retrying or mid-sync to the accounting provider. This is only about reaching the provider — whether the entries exist in SKU's own ledger is what the Data completeness checks above settle.

So an in-flight count of zero does not mean the month's books are complete. It means nothing is stuck in transit. Completeness is the job of Ledger generation — individual entries and All entries balanced, further up the checklist. For a reason-by-reason account of everything in the month that has not reached the provider — including the entries that are never meant to — use see why entries haven't reached your provider.

Entries dated in a month you have already closed sync the same way. A late bill or a correction lands in the closed month, restates it, and goes to your provider like any other entry, unless it's on a paid document or dated on or before your provider's own lock. The month's restatement panel counts those. See When a closed month changes.

The close doesn't lock your provider

Closing a month signs it off. It doesn't lock it, in SKU.io or in your provider. Only your hard close date freezes the books, and Xero and QuickBooks each keep their own, separate lock date. SKU.io reads that lock once a day and never writes one back.

Provider lock aligned, in the Sign-off section, compares each connection's lock date with your hard close date and warns when they differ, in either direction. It never blocks a close. Set your provider's lock to your hard close date, not to each month you sign off: a provider lock on a month that's only signed off stops late changes to that month reaching your provider. How to read the check, the Provider alignment tile and the warning on the Close tab, and how to line the two up, are in Keep your provider's lock aligned.

When the local copy does not cover the month

Provider documents reconciled compares your month against your provider's documents for the same month. It works entirely from the copy of those documents SKU.io keeps locally, and it refuses to report agreement it cannot actually see.

If that local copy does not span the closing month, the row says so instead of quoting a variance:

Sample QBO Connection: mirror does not cover the period

That distinction matters more than it looks. With no documents to compare, a variance of 0.00 is not agreement — it is the absence of evidence, and printing it would read as a clean bill of health. Coverage is also strict: every document type your provider can mirror must span the month, not only the types that happened to backfill. One type that failed to come across leaves the month uncovered, even when the others look complete.

Coverage is not something the close can repair for you: the fix is to refresh the local copy on Accounting → Reconciliation → Documents and then re-check the month. The steps are in fix a failing check.

The checklist row does not tell you how fresh the copy is. It carries its one-line summary and nothing else — no last-refreshed time — so a row reporting a tidy variance is not, by itself, evidence that the comparison is current. Freshness lives on the Documents lane instead: Cached through gives the latest document date covered, and a chip for each document type your provider mirrors gives how many are cached (Qbo invoice: 0, Qbo bill: 0, and so on), with the date it was last refreshed in the chip's tooltip. When the summary and the calendar disagree, believe the Documents lane.

When the copy does cover the month, the row reports what is actually wrong — an amount variance outside tolerance, unmatched documents on either side, or both — and its arrow opens Reconciliation → Periods.

Trial Balance Reconciliation: your balances against the provider's

This report, in the report pack, lines your trial balance up against the provider's own trial balance for the month end, account by account. It is the reconciliation that answers "do the two systems agree on what each account is worth", and the Trial balance reconciled to provider check reports its headline — for example, 2 of 9 accounts out · 1,301.15 total variance.

How it behaves:

• It needs a fresh provider trial balance. SKU.io fetches one on Start close, on each Re-check and on a re-sign-off, so you rarely need to capture it by hand. The check fails, rather than standing aside, when the comparison can't be made:

  • with no capture at all: not compared — no provider trial balance captured for Jun 30, 2026. Use "Capture provider balances" in the report pack.
  • when the fetch fails: not compared — couldn't capture the provider trial balance for Jun 30, 2026 and the connection and its reason;
  • when the capture is out of date: provider balances captured and the time, are out of date with the reason, — press Re-check to re-capture. A capture is out of date once it's older than Provider balances go out of date after (in hours, on Accounting → Settings → Close, under Reconciliation policy), or older than SKU.io's latest push for the month. 0 turns the age limit off.

• A closed month keeps the capture it was signed on. Each sign-off revision freezes the trial balance it was compared against. A re-sign-off fetches a fresh one for the new revision, and the earlier revisions keep theirs.

• Accounts are matched by account code. A code that differs between the two systems is not a variance, it is an unmatched pair — the two balances never meet to be compared. If a whole run of accounts shows up unmatched, suspect the codes before you suspect the figures, and check your mapping in map your accounts to QuickBooks.

• The table only holds accounts that matched. Every row you can read has a balance on both sides. Accounts that exist on one side only never become rows, which is the part worth understanding before you reconcile the report against the headline:

  • A provider-only account carrying a balance still counts as out of balance — SKU.io is implicitly claiming zero for it — and its amount is inside Total Abs Variance. So Accounts Out Of Balance can be larger than the number of rows showing false under In Tolerance. A count you can't reconcile against the rows in front of you means an account exists at the provider and not here.
  • An account of your own carrying a balance with no provider counterpart is the quieter case: it is neither a row nor part of either total. Nothing on screen says it was set aside. If the two systems should agree and the report looks suspiciously clean, suspect a code that does not match rather than a balance that does.

• The per-account tolerance starts at 0.00, so out of the box every difference is reported however small — the In Tolerance column reads false on any account that differs at all. Change it with Trial balance (per account) under Check tolerances on Accounting → Settings → Close. See close settings and custom checklist items. Rows are ordered biggest difference first, so the account worth investigating is at the top.

• It warns by default. You acknowledge it in the close dialog, which stamps the row Acknowledged at close. Turn on Inventory and trial-balance breaks block the close, under Reconciliation policy on the same settings screen, and it blocks instead: closing over it then needs a written reason and the Accounting Period Override permission (accounting.period.override), and the reason and the figures are kept on the month.

Both sides are compared in the same net-debit terms, without adjusting the sign per account type. Read a variance on an account whose natural balance is a credit with that in mind before you go hunting for a posting error.

What the three reports put on screen

All three open from the report pack into the same viewer: a band of totals across the top, then a table. The headings are generated rather than written by hand, which is why they read Sku Balance rather than SKU Balance, and why plain counts print to two decimal places — 9.00 accounts, not 9. The exported workbook uses the same headings.

Report	Totals across the top	Table columns
Trial Balance Reconciliation	Accounts Reconciled · Accounts Out Of Balance · Total Abs Variance	Connection · Account Code · Account Name · Sku Balance · Provider Balance · Variance · In Tolerance
Reconciliation Summary	Provider Variance · Inventory Divergence	Connection · Provider · Sku Total · Provider Total · Variance · Matched Count · Sku Only Count · Provider Only Count
Sync Category Reconciliation	Categories · Categories Unsettled · Sku Total · Synced Total · Excluded Total · Unsettled Total	Category · Entries · Sku Total · Synced Total · Excluded Total · In Flight Total · Needs Attention Total · Settled

In Tolerance and Settled print as true or false on screen rather than as ticks. The workbook writes the same two columns differently: a yes reads TRUE and a no is an empty cell, so don't filter a downloaded sheet on FALSE — see the exported workbook's columns. Above the totals, the viewer says when the figures were produced — Computed with a date and time on an open month, Snapshotted on a closed one. That timestamp is when the report was built, not the day the provider's figures are as at.

Sync Category Reconciliation: is every category settled?

Where the trial balance report asks about accounts, this one asks about categories of transaction — invoices, bills, credits and the rest.

It anchors on SKU.io's own total for each category, because SKU.io holds every accounting transaction whether or not it syncs, then splits that total four ways: how much reached the provider, how much is excluded by design, how much is still in flight, and how much needs attention. The Transaction categories settled with provider check reports the result — for example, 4 of 8 categories unsettled · 6,783.55.

A category is settled when nothing is in flight and nothing is stuck. Money you have deliberately chosen not to send does not make a category unsettled — excluded is a finished state, not a problem. That is the distinction the report exists to draw, and it is why the excluded column sits next to the synced one rather than in with the failures.

Two details keep the totals honest:

• Batched entries are counted once. A batch's summary entry is included and the member documents inside it are left out, so a category's total matches the ledger instead of double-counting every batched amount. See batches and the close.
• With no accounting connection the check is skipped entirely, because nothing was ever going to sync.

The check warns when any category is unsettled.

Reconciliation Summary: the month's reconciliation evidence

The third reconciliation report is the one-page evidence sheet. It carries one row per accounting connection: your total for the month, the provider's total, the variance between them, and the counts of documents that matched, that exist only here, and that exist only at the provider.

Alongside those rows it carries the inventory-versus-GL gap at month end — the same figure the Inventory reconciled to GL row quotes on the checklist (for example, 842.10 divergence (limit 1.00)). Having both on one sheet is the point: the two questions a reviewer asks about a closed month are "does it tie to the provider" and "does the stock tie to the books", and this report answers both.

It uses the same month window as Reconciliation → Periods, so the copy saved with each sign-off and the live screen agree rather than differing by a day at either edge. For what happens to these reports when the month closes, see read the month's reports and when a closed month changes.

Its Provider Variance total is your side against the provider's side for the whole month, so a zero there says the two totals agree — it says nothing about whether the documents underneath them are the same documents. That is what Matched Count, Sku Only Count and Provider Only Count are on the same row for: two sets of documents can add up to the same money and still not be the same set.

Two accounting connections on one month

Nothing about the close assumes a single provider. Provider lock aligned and Provider documents reconciled evaluate each connection separately and let the worst result decide the row — one connection out of line is enough to make the row fail, however clean the others are.

What differs is the wording on Provider lock aligned:

• With one connection out of line, the row gives that connection's own sentence, naming it, its lock date and your hard close date.
• With several, the row counts them instead, for example 2 connections disagree with the hard date.

Either way, the arrow opens the Connections panel, where every connection is listed with its own Lock date, Active or Paused state, and a Manage in Xero / Manage in QuickBooks link. Check them one at a time from there.

The same one-row-per-connection treatment appears in Reconciliation Summary and in Provider documents reconciled, whose summary names each failing connection in turn.

Trial balance reconciled to provider is the exception. It doesn't grade connection by connection: it pools every captured connection's accounts into one set of totals. A fetch that fails for any connection fails the row and names that connection. To confirm every connection was compared, open Trial Balance Reconciliation and read the Connection column. See capture your provider's trial balance.

Currency at the close

The close has no currency dimension, and knowing that up front saves a long hunt for a control that does not exist.

• No figure in the close is labelled with a currency. Not on a checklist row, not in the nine reports, not in the exported workbook: there is no currency column and no symbol anywhere, and no report separates or converts one currency from another. On a business keeping one set of books in one currency this is unremarkable. On one running several, it means the totals in the pack are unlabelled numbers — the pack cannot tell you which currency a figure belongs to, so that context has to come from you.
• The variance limits are bare amounts too. The (limit 1.00) the Inventory reconciled to GL row quotes, and the per-account tolerance behind In Tolerance, are numbers with no currency attached.
• Closing performs no revaluation. Nothing in the close restates a balance at a month-end rate, and there is no control in it that would. Treat a revaluation journal like any other adjustment the month needs: post it before you close. A revaluation posted after the close still lands in a Closed month on its date and restates it, so you re-sign-off the month. Only a month on or before your hard close date refuses it; there you'd have to lower the hard close date first.
• A cross-currency comparison is a plain subtraction. Trial Balance Reconciliation matches accounts by code and subtracts one balance from the other. Neither side's currency is shown and there is no currency-mismatch state, so an account the two systems hold in different currencies produces an ordinary-looking figure in Variance — indistinguishable on screen from a posting error, and reported as out of balance at the default tolerance of 0.00. If a variance is close to an exchange rate multiple of the balance, check the currency before you check the postings.
• Batching is the one place currency is a grouping. On Accounting → Batches, the Currency column explains itself: The currency shared by every document in the batch — documents in different currencies form separate batches. A month trading in two currencies therefore produces two sets of batches, and Ledger generation — batches wants all of them posted, not just the busiest currency's. See batches and the close.

Closing with no accounting provider connected

A business that keeps its books only in SKU.io closes months exactly the same way, and this is fully supported rather than a degraded mode.

• Every provider-dependent check stands down. The rows are dimmed, with a grey dash for a status icon and No accounting connection written underneath. They count as complete on the checklist and they block nothing. Entries synced puts it in its own words: No accounting connection — entries never sync.
• The close itself is unchanged. Data completeness, balancing, inventory and your own custom items all run as normal, and SKU.io's ledger stands on its own as the month's numbers of record.
• The report pack still builds. All nine reports are produced; the three reconciliation reports come back empty but valid, because there is no second system to reconcile against.
• Nothing nags you about locking the books elsewhere. There is no "connect a provider" prompt on the checklist, and no acknowledgement to tick for its absence.

Opened on screen, those three empty reports show the viewer's plain empty state — a file icon and No rows for this period. The dialog does not say why it is empty, so on a business with no provider connected read that emptiness as expected rather than as a fault. The exported workbook is the more explicit of the two: each of those sheets carries a Note row reading No accounting connection.

Next steps

• Capture your provider's trial balance — the one figure the close fetches from Xero or QuickBooks.
• Keep your provider's lock aligned — set your provider's lock to your hard close date.
• See why entries haven't reached your provider — every entry that hasn't synced, grouped by reason.
• The close checks — what each row measures and where its arrow sends you.
• What stops a close, and what only needs a tick — why every provider-facing check is a warning.
• Batches and the close — why some entries sync as one summary and post a few days late.
• Read the month's reports — opening the nine reports and telling preliminary figures from final ones.
• Review the ledger — the day-to-day view these checks summarise.