How SKU.io reconciles with Xero and QuickBooks

Four 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 actually compares, where the figures come from, and the two things the close deliberately will not do on your behalf.

The close reads your own records, not your provider

Every check on the checklist and every report in the pack is built from records SKU.io already holds: its own ledger, its own local copy of your provider's documents, and the provider lock dates it imported earlier. Running a close makes no round trip to Xero or QuickBooks.

There is exactly one deliberate exception. Capture provider balances, the button at the top of the report pack, pulls your provider's own trial balance as at the month end and stores it. That is a step you take on purpose, and it is covered in capture your provider's trial balance.

Two consequences follow, and they are the whole point of the design:

• A connection that is expired, paused or unreachable can never fail or abort a close. Nothing in the close waits on Xero or QuickBooks to answer, so a token that went stale overnight cannot leave you unable to sign off the month.
• But it can make the evidence stale. The checks are comparing against whatever was last brought across. If the local copy of your provider's documents stopped refreshing three weeks ago, the reconciliation rows are reconciling three-week-old evidence — and they will tell you so rather than pretend 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.

Locking the month in SKU.io does not lock it in Xero or QuickBooks

Closing a month in SKU.io locks it in SKU.io. Your provider keeps its own, separate books-closed date, and the two are only aligned because you align them.

Provider lock aligned, the single check in the Sign-off section, is where this shows up. It reads each connection's lock date and asks whether it covers the month you are closing. When it doesn't, the row names the connection and the date it is stuck at — for example Sample QBO Connection locked to 2026-05-31 while June is being closed. The arrow opens the Connections panel, where each connection shows its Lock date with the explanation:

The provider's books-closed date. Entries dated on or before it are blocked from syncing — the provider would reject them.

Four things are worth knowing about that date:

• SKU.io reads it, once a day, and never writes one back. You set the lock inside Xero or QuickBooks yourself. There is no control anywhere in the close that pushes a lock date outward.
• An imported lock is enforced here too. Once read, your provider's lock date joins SKU.io's own locks and feeds the same effective lock on posting. That is why reopening a month can leave it still locked: the reopen removes the lock the close created, and the provider's lock is untouched. See reopen a closed month.
• A lock lifted at the provider clears itself here. When the daily read finds no lock date, any previously imported one is removed, and the check stops warning without anyone doing anything.
• Paused connections are skipped by the daily read — and a connection whose authorisation has lapsed is one of them. The Connections panel has only two states, Active and Paused, so an expired or revoked authorisation shows up as Paused like any other pause; the banner underneath names the reason — Sync is paused (…) — no operations are being pushed or pulled — and offers Reconnect. Either way the connection keeps whatever lock date it had at the time, and nothing refreshes it until you reconnect. This is the most common way a lock date goes quietly stale, because the row keeps quoting the old date as though it were current.
• A read that fails leaves the old date standing, with no mark on the row. If the provider is reachable but the read errors, the previously imported lock date stays exactly as it was. Nothing on the checklist says the read failed, so treat a lock date that never moves as worth checking in the Connections panel.

The check warns; it never blocks. Closing in SKU.io first and locking the provider a day later is a normal way to work — you acknowledge the row and move on.

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 captured provider trial balance first. Without one, the check does not fail — it stands down, and the reason printed under the row is:

  No provider trial balance captured for this period — use "Capture provider balances" in the report pack below

• 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. It is configurable, but not from a settings screen: see close settings and custom checklist items. Rows are ordered biggest difference first, so the account worth investigating is at the top.

• It warns, it never blocks. A genuine ledger discrepancy should not hold a month hostage — but it must be acknowledged in the close dialog, which stamps the row Acknowledged at close on the frozen checklist for good.

One reason it warns rather than blocks: both sides are compared in the same net-debit terms, and normalising the sign per account type is still to come. 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 frozen into the close 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 frozen figures, staleness and drift.

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:

• With one connection behind, the row names it and the date, as in Sample QBO Connection locked to 2026-05-31. A connection with no imported lock date at all reads locked to no date.
• With several behind, the row counts them instead — for example 2 connections behind 2026-06-30 — because a list of names would not fit on one line.

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, and it is worth knowing which way it leans. It does not grade connection by connection: it pools every captured connection's accounts into one set of totals, and a connection with no capture for that month end adds nothing at all — no rows, no variance, and no note anywhere that it was left out. So this row errs towards looking clean rather than towards failing, and the only way to confirm it covered everything is to 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. Once the month is closed its lock stops new entries posting on or before the month end, so a revaluation you meant to sit inside the month can only get there through a reopen.
• 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 deliberate call out to Xero or QuickBooks.
• 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.