Processing Incoming Money From Customers
In Part 1, I sorted 44 customers by country and industry. No money was attached yet. In Part 2, real revenue gets added to each one. Once I did that, five things stood out. The biggest one: just 5 customers make up 77.5% of all the money coming in. That means a quiet month might not be random — it could mean one of those five customers paused.
Part 1 covered how I sorted these 44 customers — country, industry, payment terms, how often they order. None of it had a euro sign on it yet. This part is different. Here, real revenue gets attached to each customer, pulled from 12 months of the general ledger. Some of it took real digging. Several customers had no country listed anywhere obvious. To confirm it, I traced a VAT number or opened old invoices by hand.
Finding 1: the business is far more concentrated than it looked
I added a "% of total revenue" number to each customer. One thing was obvious right away: the money was very concentrated.
| Rank | Customer | Region | % of revenue | Running total |
|---|---|---|---|---|
| 1 | Customer 39 | C01 - Central Europe | 21.9% | 21.9% |
| 2 | Customer 09 | C02 - Northern Europe | 16.6% | 38.6% |
| 3 | Customer 22 | C01 - Central Europe | 14.0% | 52.5% |
| 4 | Customer 14 | C04 - Western Europe | 13.6% | 66.2% |
| 5 | Customer 10 | C03 - East Asia | 11.3% | 77.5% |
| 6 | Customer 38 | C05 - Central Europe | 5.0% | 82.5% |
| 7 | Customer 34 | C01 - Central Europe | 3.7% | 86.1% |
| 8 | Customer 13 | C06 - Eastern Europe | 3.5% | 89.7% |
| 9 | Customer 18 | C03 - East Asia | 3.3% | 92.9% |
| 10 | Customer 28 | Oceania | 0.6% | 93.5% |
The top 5 customers made up 77.5% of all money received in 12 months. The top 10 made up 93.5%. That leaves 34 customers. Together, those 34 made up less than 7% of total cash in.
A general ledger export doesn't show this on its own. It only becomes visible once the data gets organized this way. A 13-week forecast should warn a business weeks before a shortfall — not confirm one after it already happened. A number like this shows exactly which five customer relationships that early warning depends on.
Finding 2: country concentration compounds the risk
Revenue was concentrated by country too, not just by customer.
| Country - Region | % of revenue |
|---|---|
| C01 - Central Europe | 39.6% |
| C02 - Northern Europe | 16.6% |
| C03 - East Asia | 14.6% |
| C04 - Western Europe | 13.6% |
| C05 - Central Europe | 5.0% |
| C06 - Eastern Europe | 3.5% |
One country alone made up close to 40% of total incoming cash. The top three countries together covered almost three-quarters of it. Add this to the customer concentration above, and the picture is clear: this business's cash depends on a few relationships, in a few places. Better to know this before a regional slowdown or a currency shock hits — not after.
I also noticed that the company has almost no presence in several regions. Expanding into these markets could diversify revenue sources and reduce dependence on a small number of countries.
Finding 3: payment reliability was better than assumed, with clear exceptions
Every customer got a payment reliability score. 1 means very poor. 5 means excellent. The score came from real payment history, not from what the contract said.
| Score | Customers |
|---|---|
| 5 — excellent | 37 |
| 4 — good | 3 |
| 3 — fair | 1 |
| 2 — poor | 1 |
| 1 — very poor | 2 |
37 of 44 customers scored a 5. Most of this customer base pays reliably. This matches the prepayment pattern from Part 1. A small group scored 1 to 3. Those customers needed closer, individual attention — I didn't blend them into the "usually fine" average. This mattered for the forecast. For most customers, trusting the invoice due date was fine. For a few specific customers, I built in a real buffer instead.
Finding 4: exceptions were hiding in the accounts receivable balances
Most customers carried a zero AR balance. That fits a business built on advance payments. But two kinds of exception stood out. Both were worth showing on their own, not averaged away.
| Type | Customers | Share of annual revenue |
|---|---|---|
| Owed to the business (AR debt) | 8 | about 4% |
| Paid in advance (overpayment) | 5 | about 8% |
The 8 AR balances were tracked individually in a supporting list with the customer, amount, and expected payment date. The forecast itself still showed only one total per week. This lets each payment fall into the correct week and makes it easy to update the forecast when a customer pays.
The 5 overpayments represent cash already received but committed to future deliveries. If an order is cancelled, some of that cash may need to be refunded. That's a liquidity risk that should be tracked separately, not hidden inside the forecast.
Finding 5: not all future cash can be forecast the same way
Part 1 already showed how often these same 44 customers order. Most fell into a "every 2 to 6 months" pattern. The plan was to use this directly: know how often a customer orders, then pencil in the next order. That plan mostly didn't work.
A customer with no order in 9 months is a very different case from one who ordered last month. But neither one gets scheduled into the actual forecast on frequency alone. Both need something more solid first — a confirmed open order, or an issued invoice. Order frequency was useful for spotting customers worth reviewing, but not for forecasting cash in a specific week.
I found that incoming cash naturally fell into three groups. Each group needed a different forecasting method.
| Level | What is known? | How it is forecast |
|---|---|---|
| 1. Known cash | Confirmed customer orders, issued invoices, contract milestones or other evidence that payment is expected. | Each receipt is entered individually with its expected payment date. |
| 2. Likely future orders | The sales team expects a deal to close, but it is not yet confirmed. | Estimate the expected value using probabilities. For example, a €100,000 opportunity with a 70% chance contributes €70,000 to the forecast. |
| 3. Unknown future orders | No order exists yet. These are customers who place and pay for orders on the same day, so there is nothing to forecast individually. | Use historical averages instead of guessing individual customers or dates. |
For the third group, I separated historical receipts into two categories: cash linked to known orders or invoices, and cash that arrived without any prior evidence. Only the second category was used to calculate the average.
I calculated the average weekly receipts from these "unknown" orders over the previous 13 weeks. That average became the expected weekly cash inflow for this category throughout the 13-week forecast.
Every week, I remove the oldest historical week, add the newest actual week, and recalculate the average. As soon as an order becomes known, it leaves this statistical category and is forecast individually under Level 1. This keeps the forecast based on the best available information while avoiding guesses about customers or orders that do not yet exist.
Why this phase matters to a client
This step gives value on its own, even before the forecast exists. Some business owners may have never seen their customer base laid out this way. They usually learn something new — where the real dependency sits, which relationships actually carry the business, and which "regular" customers aren't as regular as they assumed. The forecast gets built on top of all this. But this table alone is often worth having.
This is Part 2 of a 5-part case study. Part 3 — building an engine that updates itself — will be published soon.