Why Collections Tracking Stops Adding Up

Month end arrives and nobody can give the real figure. Revenue is known, what has actually been collected is not, and who still owes you is anybody guess.

This usually comes from a fragmented record rather than a lack of discipline. The quote is in a spreadsheet, the invoice is in accounts, the payment is on a bank statement, and the only place they come together is somebody memory.

Collection is not a single number

This is the mistake we see most. The sale record has one amount field and real life does not fit in it.

The deposit taken, the instalments still due, the current balance and the overdue portion are separate pieces of information. Trying to track them all as one figure breaks the moment a partial payment arrives, and people start keeping notes on the side.

When a payment goes in, the balance should move on its own. A balance worked out by hand becomes wrong the first time somebody forgets, and it never recovers.

Which version of the quote went out

The customer usually remembers the second or third version and you remember the first. That is exactly where the dispute starts.

Versioning a quote is not a complicated feature but it saves a lot of work. What was sent, on which date, with which lines stays on the record, and the argument closes in a minute.

What the invoice is attached to

If an invoice is not linked to a sale, that sale to a quote, and an incoming payment to an invoice, then reconciliation is being done by hand.

Manual reconciliation works in a small company. As the customer count grows it takes the whole first week of the month, and during that week nobody is selling.

Overdue accounts should rise on their own

If finding a late payment means opening a report, that report gets opened once a week. The cost of being late is daily.

An overdue record needs to rise to the top of the list by itself, and who chases it and when should be openable as a task. As long as follow-up depends on somebody remembering, it stays irregular.

If you sell in more than one currency

The most common mistake here is not storing the rate at the moment of the transaction. The quote went out in dollars, the payment came three months later, and the report uses today rate.

The result is that your historic reports change every day. Last month revenue looks different this morning and nobody trusts the number.

The rate at the point of sale has to be stored on the record. When converting to a single currency for reporting, that fixed rate is what gets used, not today one.

How money should be stored

Technical, but it affects the outcome directly. Holding money as a decimal number lets small rounding errors accumulate over time.

We hold money as a whole number of the smallest unit. A hundred pounds is stored as ten thousand, and no total ever drifts. This is a choice that is very hard to correct later, so it gets made correctly on day one.

It does not replace your accounting software

Let us be plain about this. Accounting software keeps the statutory books and there is no need to change it.

A system like this handles the day to day. The two run alongside each other and the transfer between them is planned from the start. The same applies to ERP. This is not an ERP, it is a piece that talks to one.

The only thing to decide is which side holds the truth. If both can change the same record and no rule has been written, they drift apart within months.

Where e-invoicing sits

Statutory electronic invoicing goes through an authorised provider. The system does not do that on its own.

What it does is hold the invoice record and connect to that provider. The connection is planned as separate work, and we need to know which provider you use from the start.

Who sees what

Revenue and margin are not information for everyone. A salesperson can see the balance on their own accounts without seeing the figures for the whole company.

That is not a question of trust, it is a question of boundaries. A system where everyone sees everything does the widest damage on the day somebody leaves.

Partial payments are where it breaks

Most systems handle a full payment well. Things fall apart on partial ones.

The customer pays four thousand against a ten thousand invoice. It is not closed, but it is not fully open either. That middle state does not exist in the spreadsheet, so somebody writes a note on the side and that note never reaches a report.

Holding payments as records separate from the invoice solves it. Several payments attach to one invoice, the balance falls out on its own, and nobody does arithmetic.

Who calculates the amount

This looks technical and costs real money. If the amount due arrives from the browser, then the amount due can be changed.

The amount is always calculated on the server and a price sent by the client is never trusted. It is a well known rule on the e-commerce side and a commonly missed one on internal collection screens.

The question of who entered it

When a payment record is changed afterwards and there is no sign of who did it, the error cannot be traced.

Every payment record carries who entered it and when. That is not about blame, it is about finding where the mistake started. When a figure does not add up, this is the first place to look.

Where to start

None of this has to go in at once. We usually start with quotes and the sale record, because that is the head of the chain.

Payments and balances come next. The invoice link and the accounting transfer come last, because that step depends on what the other system exposes and is not ours to decide alone.