How to prepare a weekly customer credit review

A weekly review fails for a predictable reason. The team pulls one report that mixes everything together, reads it as a single number, and then argues about the number instead of about the customers behind it.

The method that works is the opposite. Assemble three views that are deliberately kept separate, because each answers a different question and mixing them hides all three:

1. Exposure. How much money is out, and with whom.
2. Aging movement. Whether that money is getting older, and where.
3. Limit context. Whether the amount out is still inside the decision somebody made about that customer.

Then produce one exception queue from those three views, work it in order, and write down each decision with the reason attached. That is the whole method. The rest of this page is the mechanism.

An exception is an account that broke a rule the team already agreed on. The rules should be written down before the review, not invented while reading it, and each item in the queue should carry the rule that surfaced it. An exception without its reason attached is just another row to argue about.

A workable starting set of rules, in roughly the order most teams find useful:

• over the approved credit limit, with no hold decision recorded
• past due balance moved into an older bucket since the last review
• payment behavior slowed with no dispute code attached
• risk rating worsened since the last review
• no review recorded in the last twelve months
• flagged in consecutive reviews without a decision being recorded

That last rule is the one most teams add late and value most. A single flagged week gets explained away. The same name flagged for four weeks running is a pattern, and it only becomes visible if the queue remembers what it flagged last time.

Rank the queue by what is at risk rather than by balance alone. The largest balance is often the account with the most attention on it already.

The review is not finished when the queue is read. It is finished when each item has a recorded outcome. Without that record, the next review starts from zero and the same five accounts get rediscovered every week.

For each exception, record four things:

1. What was decided. Hold, release, raise the limit, reduce it, chase, escalate, or accept and watch.
2. Who decided it. A named person, because a credit decision belongs to someone.
3. The reason. One or two sentences with the figures that drove it.
4. The date and the review trigger. When this gets looked at again, or what would bring it back sooner.

Two rules keep this honest. First, every number in the review has to tie back to the source extract, and if a figure does not reconcile the review does not go out. Second, anything inferred rather than measured is labeled as inference, so a reader can tell the difference between "this balance is 61 days past due" and "this customer appears to be stretching payments".

Keep the same format every week. The comparability between review two and review one is worth more than any single improvement to the layout.

Three practical points decide whether the cadence holds.

Fix the extract before you fix the analysis

Start from an export the team already trusts and write down what every column means, confirmed with someone who knows the source. Field mapping is where reviews quietly go wrong, and a report built on the wrong column is worse than no report.

Keep the format identical

Same sections, same order, same definitions every week. Comparability is the whole point of a cadence. Improvements to the format should be batched and dated, so a reader knows when a definition changed.

Let the queue carry memory

Track how many consecutive reviews each account has been flagged in, and whether a decision was recorded. Those two fields turn a weekly snapshot into a trend, at almost no cost.