MELLORCATalk to Mellorca
Patterns

Data, Reporting & Management Visibility

Why Finance Reconciles Information That Systems Already Hold

The facts needed to close the month are already in the business, yet finance spends days matching them by hand. The cause is how the systems were set up, not how finance works.

Mellorca Patterns2026-10-09

Observable condition

Every month the finance team spends days matching things up. Sales orders against invoices. Bank receipts against debtors. Payroll hours against project codes. Supplier statements against the ledger. Each match is routine, and almost all of them agree in the end. The effort is not in finding errors but in proving that there are none.

The strange part is that the information needed to do this matching already sits in the company's systems. The order has a reference. The invoice quotes it. The bank statement carries a customer's payment reference. A person is nonetheless needed to find these pieces in three places and confirm that they belong together.

An illustrative example: a Port Elizabeth automotive-parts wholesaler issues about 1,800 invoices a month. Customers pay by EFT, often combining several invoices in one payment and typing their own references. Two bookkeepers spend most of the first week of every month allocating payments, chasing short-payments and reconciling the debtors ledger to the sales report. The closing of the books is always the fifth working day at the earliest.

Realisation

The realisation is that reconciliation is mostly a symptom of systems that do not share keys. If the sales system, the billing tool and the bank feed each recorded the same reference for the same transaction, the match would be performed by software in seconds. When they do not, the match is performed by a trained person, using memory and judgement to bridge gaps that were never closed at source.

Reconciliation has a real, legitimate purpose: it is how a business checks that its records agree with the outside world and with each other. The problem is the volume of routine matching that precedes the genuine checking. Time that should go to examining exceptions goes into confirming thousands of matches that were never in doubt.

IBM's overview of data reconciliation describes the process as comparing records from different sources to confirm that they agree, and notes that automation can handle the routine matching. The same principle applies to a business of any size: if a rule can describe a match, a system can apply it.

Realisation prompt: ask your finance team what proportion of their reconciliation time goes on items that turn out to be correct. The answer is usually most of it.

Identification

This is a pattern of manual reconciliation of data that systems already hold. The visible symptom is a slow month-end and a finance team that looks like a data-matching department. The common assumption is that this is simply what finance does, or that the team needs more staff or better spreadsheet skills. The structural cause is that the systems feeding finance do not carry shared identifiers or share their records, so the matching has to be done by people.

The published Pattern when finance teams become data clean-up teams describes the wider drift of finance into data repair. This Pattern concentrates on the routine matching step, and on what it takes to turn that step into a system function. The Discovery note why revenue leakage only shows up at month-end reconciliation shows what the late discovery costs.

Diagnosis

  • No shared transaction reference. The order number, invoice number and payment reference are created independently, so nothing links them mechanically.
  • Customers choose their own references. Payments arrive with abbreviated names, missing invoice numbers or one payment covering many invoices.
  • Systems are updated at different times. Sales records an order today, billing raises the invoice tomorrow and the bank shows the receipt next week. Timing differences appear as breaks.
  • Master data differs. The same customer has slightly different names or account codes in the CRM and the ledger, so records fail to match. The Insight how duplicate customer records are created describes how this arises.
  • Manual overrides are untracked. A price changed on an invoice or a discount agreed by phone appears in finance but not in sales, and the difference surfaces only at reconciliation.
  • Rules live in people's heads. The bookkeeper knows that customer X always pays two invoices together, but the system does not.
  • Retained exports stand in for connections. Data is copied into spreadsheets for matching, adding a further copy to reconcile. Microsoft's documentation on Dataverse describes the alternative of storing business data once in a shared, structured platform rather than in loose files.

Commercial impact

The commercial value at stake is finance capacity, speed of closing, cash collection and the reliability of reported figures.

The obvious cost is time. If two people spend the first week of every month matching records, that is roughly a fifth of their working time. The cost is not only salary: the same people could be analysing margins, chasing overdue accounts or preparing forecasts.

The second cost is delay. Management receives results on the fifth or tenth working day, by which time the month is a memory and corrective action has to wait. Late reporting also affects compliance. VAT returns and provisional tax calculations depend on accurate records, and SARS deadlines do not move because a reconciliation is still in progress.

The third cost is cash. Unallocated payments leave customers appearing overdue. Collection staff chase accounts that have paid, which irritates good customers, while genuinely late accounts receive less attention. The Pattern when sales, finance and support disagree about the same customer explains how this friction spreads beyond the finance department.

The fourth cost is risk. Manual matching is repetitive and error-prone. People who match hundreds of lines a day will eventually accept an incorrect pairing, and a duplicate payment or a missed credit note may go unnoticed until an audit.

Common misidentification

The usual response is to hire another bookkeeper or to ask the team to work overtime at month-end. Both add capacity to a process that should not need it. Another response is to design a better reconciliation spreadsheet. A good spreadsheet makes the manual work tidier, but it keeps the work manual and adds another file to maintain.

A third response is to replace the accounting package. A new ledger will still receive the same unconnected inputs, so the reconciliation workload usually follows the business to the new system. The underlying issue is how data arrives, not what the ledger is called.

Possibility

In a better state, every sales order generates an invoice that carries the order reference. Customers are given a unique payment reference per invoice or per account, printed on the invoice. Bank feeds import automatically, and rules match receipts to invoices on those references. The routine majority of items are matched without human touch, and the team sees only a short list of exceptions: short-payments, unrecognised references, and invoices with no order.

Month-end then becomes a review of exceptions rather than a matching exercise. Closing takes days instead of a week or more, and finance time moves from checking that records agree to explaining why a difference exists.

Intervention

  1. Time the matching. Over one month, record the hours spent on each type of reconciliation and the share of items that needed correction. Start with the largest block of time and the lowest error rate.
  2. Find the missing key. For that reconciliation, identify what field would let a system match the two sides, and where it is lost.
  3. Carry the reference through. Make the order, invoice and payment reference travel together, and give customers a clear reference to quote when paying.
  4. Write down the matching rules. Document the habits of your most experienced bookkeeper, such as customers who pay in batches, so software can apply them.
  5. Use the automatic matching you already own. Many accounting packages and bank feeds include rule-based matching that is switched off or unconfigured. The Insight how to decide what should be the system of record will help settle where the master version of each record lives.
  6. Review exceptions, not everything. Redirect human attention to differences above a threshold, and track the match rate monthly.

Diagnostic questions

  • How many working days does it take to close the month, and how many are spent matching records?
  • What percentage of reconciled items turn out to be correct?
  • Does one reference travel from order to invoice to payment?
  • Which matching rules exist only in someone's head?
  • Is automatic bank matching switched on, and how many receipts does it allocate?

Bottom line

Finance reconciles what systems already hold because the systems were never told how their records relate. Carrying a single reference through the chain, writing down the matching rules and letting software do the routine work turns reconciliation from a monthly marathon into a short review of the items that genuinely need a person.

Sources and further reading

Related Mellorca reading

Article summaryThe facts needed to close the month are already in the business, yet finance spends days matching them by hand. The cause is how the systems were set up, not how finance works.
Explore our solutionsStart a conversation