How customer credit is set up in finance and ERP systems

Customer credit usually lives inside the receivables and sales modules of the ERP. Each customer record carries a credit limit and a risk category. The system checks exposure when an order is entered or released, and any order that breaches policy is held for a credit analyst to decide.

Policy turned into configuration

A written credit policy rarely survives intact once it reaches the system. What gets configured is a reduced version of it. That version includes risk classes, default limits for new accounts, payment terms tied to each class, and tolerance rules that say how far over the limit an order can go before it stops.

The gap between the document and the settings matters. A policy might say high risk customers need prepayment, while the system simply assigns them a low limit and lets small orders through. Anyone changing the process should compare the two side by side before touching either.

The customer master and credit segment

Most systems split the customer record. General data sits in one place. Credit data sits in a separate segment, often maintained by a different team with its own access rights. That segment holds the limit, the risk class, the date of the last review, and sometimes a link to a parent company so that exposure can be rolled up across related accounts.

Group limits cause frequent confusion. A subsidiary may look healthy on its own record while the parent is already over its combined ceiling.

New account applications

Applications tend to arrive outside the ERP, through a web form, a sales portal or email. A workflow tool or the CRM gathers trade references, bank details and signed terms. Approval routing is usually based on the requested limit, so larger requests climb to more senior approvers. Only after sign off does someone create or release the credit segment in the ERP.

This handoff is where manual rekeying creeps in, and where limits get entered wrong.

Scoring and outside data

Many teams subscribe to a credit bureau feed. Scores and payment indices flow in on a schedule and either update the risk class automatically or raise an alert for review. Some systems build an internal score from payment history, days beyond terms and dispute frequency. Analysts look at how scores have moved over time, not just the latest reading, because a slow slide says more than a single bad month.

Forecasting future credit needs is often done in spreadsheets. Sales plans, seasonal peaks and expected new customers are set against current limits to see where headroom will run short.

Automatic checks on orders

The credit check is the part most people notice. It can fire at order entry, at delivery creation or at goods issue. Exposure usually counts open invoices plus open orders, and sometimes items shipped but not yet billed. When the total breaches the limit, or when an invoice is overdue past a set tolerance, the order goes on credit hold.

Released holds should leave a trail showing who released them and why. In older setups that trail is thin.

Periodic reviews, suspension and reinstatement

Existing accounts are reviewed on a cycle driven by risk class, plus ad hoc reviews triggered by alerts. A review may raise or cut the limit, change terms, or move the account to a blocked status. Suspension typically sets a block flag that stops new orders while leaving billing and cash application open. Reinstatement reverses the flag once payment arrives or a plan is agreed.

In public sector receivables, seriously delinquent debts may also be reported to credit bureaus and to central oversight bodies, with formal cancellation notices when debt is written off.

Reports the team relies on

Standard outputs include aged debt by customer, accounts over limit, orders on hold, and limit utilisation by risk class. Collection reports show promises to pay and dispute status. Many of these come from a reporting layer or BI tool fed by the ERP, so definitions can drift from what the source system shows.

Questions to ask the people who run it

What actually happens when an order hits a credit hold, and how quickly does someone look at it?

Who can release a hold, and do salespeople ever ask for releases through informal channels?

Which parts of the written policy are enforced by the system and which rely on judgement?

How are new accounts set up when sales is pushing for a first order the same day?

When did each high risk account last get a proper review, and where is that recorded?

Do bureau scores change anything automatically, or does someone read them and decide?

Are parent and subsidiary accounts linked, and who keeps those links current?

Which reports does the team trust, and which do they quietly rebuild in a spreadsheet?

What happens to a suspended account when the customer pays, and who notices?

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.