Process customer credit: what to automate, what stays human, and the data it needs

Software and AI can score routine applications, monitor existing accounts, produce credit and collection reports and apply holds the policy spells out. People must set the policy, handle exceptions and approve reinstatements that carry risk. All of it depends on clean, linked customer and payment data.

Steps a system can run today

New account applications are the clearest case. A scoring model can pull bureau data, check the applicant against internal history and return a decision with a suggested limit. For small, standard accounts that decision can stand on its own. The credit team only sees the ones that fall outside the rules.

Reviewing existing accounts also suits automation. A system can watch payment behaviour, days past terms, disputed invoices and bureau alerts every day. When an account crosses a trigger, it raises a flag. Manual reviews tend to happen on a calendar. A machine does them whenever something changes.

Suspension works the same way when the rule is explicit. If the policy says orders stop once an account goes past a set limit or a set age of debt, the order system can enforce that without anyone touching it. The same goes for lifting a hold once payment clears.

Reporting is largely mechanical. Ageing, exposure by segment, limit usage, collection status and accounts on hold can all be generated and distributed on schedule. Where delinquent balances must be passed to credit reporting agencies or to an oversight body, the extract and submission can run from the same data.

AI is useful for reading the unstructured parts. It can summarise financial statements, pick out relevant news about a customer, or sort dispute notes into categories. Its output should feed a credit analyst's judgement. It should not be the judgement.

Where a person has to decide

Credit policy is a commercial choice. How much risk the business will carry, which customers deserve flexibility and when sales growth outweighs exposure are questions for finance and commercial leaders together. A model can show the trade off. It cannot own it.

Large or strategic applications need an analyst. So do any where the data is thin, the structure is unusual or the customer is a related party. Forecasting future credit requirements also needs people. It depends on sales plans, pricing changes and market conditions that sit outside the ledger.

Reinstating a suspended account often involves a conversation. The customer may have a payment plan, a dispute that explains the arrears, or a new guarantee. Someone has to weigh that and accept the risk by name. Credit memos and adjustments that resolve disputes also need a person who understands why the balance moved.

What the data must look like first

Each customer needs one record. Duplicate accounts across entities or systems hide true exposure and let a blocked customer order under another name. Parent and subsidiary links must be mapped so limits can apply at group level where the policy says so.

Payment history has to be accurate at invoice level. If cash is applied on account and never matched, the system cannot tell a late payer from a customer whose remittance was simply never allocated. Disputed items need a status that the scoring logic can read. Otherwise genuine disputes count as bad debt behaviour.

The policy itself must be written as rules a system can execute. Vague wording such as "review where appropriate" cannot be automated. Limits, triggers, approval levels and exception routes all need to be explicit and agreed.

Bureau data feeds should be contracted, current and matched to the right legal entity. Credit limits held in the order system and in the receivables ledger must agree. A model trained on past decisions inherits past bias, so the history used to train it deserves a check before anyone relies on it.

Questions to ask the people who run it

• When an order is blocked for credit, who actually releases it, and how often does sales go around the block?
• Which customers get treated differently from what the policy says, and why?
• Where do the real limits live: in the system, in a spreadsheet, or in someone's memory?
• How do disputed invoices show up when an account is reviewed?
• What makes an analyst override a bureau score?
• Which reports does anyone read, and which are produced out of habit?
• When a suspended customer is reinstated, what evidence is kept, and who signs it off?
• Are there customers set up more than once, and does anyone reconcile them?
• What happens to unapplied cash, and how long does it sit before someone matches it?

The answers usually reveal informal rules that never reached the policy. Those rules either need writing down before automation or need to be retired on purpose. Building a system around the documented process alone tends to produce blocks that the business immediately learns to bypass.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.