“How Much Are We Owed?” Why Recalculate Every Time?
Sales were recorded and customer transfers had arrived, yet finding the outstanding receivables still meant gathering both sets of records and calculating the balance again.
Conceptual illustration. The case is real; company details are disguised.
Before March 2023, bank transaction data went to the collections team each afternoon. The next day, incoming transfers were copied into a spreadsheet. Transfer descriptions helped identify senders, and payments were then matched against sales in the operational system. The money had arrived, but its connection to a customer still had to be assembled elsewhere.
Every question about receivables triggered the same work. Sales data was gathered from the system, payments were totalled from the spreadsheet, and the difference was calculated. The next request meant reopening both sources. Recording transactions had yet to produce a shared figure that could serve as the starting point for collections.
This affected conversations with customers. Collections needed clear figures: what had been sold, which payments had arrived, and what remained outstanding. Until matching was complete, that starting point was delayed too. The problem lay in separate information flows, even though both sales and payments had already been recorded.
As head of the IT Division, I worked with the team to move payment recording into the system that also held sales. The aim was simple: once the source of a payment was identified, the system linked it to the customer. Receivables balances then came from the same records, without rebuilding a report from two places each time.
The accounting application remained in use for payment reconciliation and official bookkeeping. This change organised operational work before and around that bookkeeping. Collections gained a starting point from connected order and payment data, while responsibility for reconciliation in the general ledger remained within the accounting process.
The process began with bank transactions. Finance AP, the team handling company payables, supplied the data, and Finance AR, responsible for receivables and collections, uploaded it. The collections team assigned each incoming transfer to a customer that same day. Unclear senders were confirmed with customers and sales administration, keeping identification an assigned responsibility.
Complete customer data also became part of the process from the start. Registration required an official contact in the customer’s finance department. This supported both payment identification and collection follow-up. The contacts needed for collections became company records, rather than information held only by individual staff members.
In the 2023 implementation, the receivables ledger showed a summary by customer group, followed by monthly details. Users could trace orders and payments through to invoice details. Each total had an explanation behind it. Questions about balances led to the underlying transactions, rather than another round of gathering data from scratch.
Outstanding receivables were also divided into amounts already billed and amounts not yet billed. That distinction determined the next task: customers who had not paid and customers who had not been billed required different follow-up. Collections could start from order data without waiting for all payment matching to finish, while transaction histories remained available for closer examination.
Responsibilities connected the data sources to follow-up. Sales administration completed customer identities, Finance AP supplied bank transactions, and Finance AR identified payment sources and contacted customers. The collections supervisor monitored balances and bills needing action. The IT team maintained the recording functions. These tasks met in shared transaction records, so reports followed work already done throughout the day.
By September 2026, incoming payment identification was still running, but the internal receivables ledger view was no longer working. Receivables figures were read from the accounting application while rebuilding the view remained the next task. The change in where reports were read needs to be distinguished from payment identification, which continued daily.
My lesson from this work: recurring business questions should be answered through connections built between records as transactions happen. Assigning payments to customers and linking them to sales gives collections a clear starting point. A report’s usefulness depends on how its data is maintained each day, long before someone asks for the final figure.