NearSync Help

Finance

Reconciliation Checking that what customers owe you and what the ledger says agree, and finding out where they do not.

Reconciliation compares two things that should be identical: the detailed records, and the general ledger's summary of them.

The two comparisons

Receivables. The sum of open invoices against the ledger's receivables account.

Payables. The sum of unpaid expenses against the ledger's payables account.

Both use base-currency amounts, so a business trading in several currencies compares like with like.

What drift means

Any non-zero difference means a transaction touched one side and not the other.

That is the whole diagnostic. In a system where everything posts automatically, the two figures should be identical by construction, so a difference is evidence of something specific rather than a rounding artefact to be waved through.

Small drift is not acceptable drift. A few units of currency is as much a broken link as a few thousand, and it is easier to find while it is small.

Finding where it lives

Both comparisons drill down: receivables by customer, payables by vendor.

That is what turns a number into a task. A drift of some amount is unfindable; a drift concentrated in one customer is a specific invoice, and looking at that customer's records usually resolves it in a minute.

Start with the largest contributor, and be aware that a small net drift can hide two large opposite errors, which is why the breakdown matters more than the total.

Two ledgers that should agree

Worth being precise about what is being compared, because the words are similar.

The sub-ledger is the detailed record: the invoices, the expenses.

The control account is the general ledger's single summary line for all of them.

Every transaction should move both. The comparison here is the check that it did, and it is the standard control in any accounting system, done automatically rather than by exporting two reports.

The usual causes

A payment recorded in the wrong place. Money applied outside the normal flow, so the invoice knows and the ledger does not.

A manual journal touching a control account. Posting directly to the receivables account bypasses the invoice sub-ledger. Control accounts should be moved by transactions, not by hand.

Something part-created. A process that failed halfway, leaving one side written.

A currency conversion applied inconsistently, which produces small persistent drift rather than one obvious gap.

When to run it

Before every close. Drift in an open period is fixable at source; drift in a closed one has to be corrected by adjustment.

Monthly at minimum, and weekly for anything high-volume.

The argument for frequency is that a difference found within a week is one transaction, and the same difference found after a quarter is somewhere in three months of activity.

Run it before you need it

The habit that makes this cheap is running it weekly rather than at month end.

Drift found within a week is one transaction and one conversation. The same drift found at quarter end is somewhere in three months of activity and takes an afternoon.

It takes under a minute when clean, which is most of the time, and that is the argument for the frequency.

Fixing it

Find the transaction, do not plug the gap. A journal entry that makes the two sides agree without explaining why they differed converts a findable problem into a permanent lie.

Correct at source where the period is open. Fix the payment, the entry, whatever it was.

Where the period is closed, post an adjustment in the current period with a description naming what it corrects.

Base currency, deliberately

Both comparisons use base-currency amounts on both sides.

That matters for a multi-currency business, because comparing a sum of invoice amounts in mixed currencies against a ledger account in base currency would show drift that is not drift, and the real difference would be invisible inside it.

Why this exists

In a system with a separate accounting package, reconciliation is a large monthly job: two systems, two versions of the truth, and hours spent establishing which is right.

Here the sub-ledger and the general ledger are the same database, so they should already agree, and this surface is a check rather than a reconciliation in the traditional sense. When it is clean, which it usually is, the whole exercise takes a minute.

That is the right expectation to hold. If it is regularly not clean, that is a signal about a process rather than a task to be repeated, and the pattern in the breakdown will usually name it.

When to run it

Weekly for anything with volume, monthly at minimum, and always before a close.

Before the close is the non-negotiable one. Drift in an open period is fixed at source; the same drift after the lock has to be corrected by adjustment in the following period, which is more work and leaves a permanent explanation in the books.

What a clean result looks like

Zero drift on both comparisons, which in a properly working system is the normal outcome rather than an achievement.

That expectation is the useful part. In a two-system arrangement, small differences are routine and get investigated only when they grow. Here they should not occur at all, so any difference is worth ten minutes immediately.

Reading the breakdown

The by-customer and by-vendor views are where the answer is, and there are two shapes.

One large contributor is a single broken transaction, and it is usually found in a minute.

Many small ones is a process problem rather than an incident, typically a conversion applied inconsistently or a step somebody performs by hand. Fixing one of them fixes nothing; the pattern is the finding.

What it does not cover

Your bank. This compares internal records against internal records. Matching them against a bank statement is a separate exercise and is not part of this surface today.

Anything outside receivables and payables. Other control accounts are not compared here.

5 minUpdated 28 July 2026

Did this answer your question?

No, ask a person