Acumatica · Reports

Acumatica Customer Credit Analysis Report

Acumatica Customer Credit Analysis Report is one of those reports every business needs and almost no business has a clean implementation of.

John Kihiu12 min read

A customer credit analysis report is the one collections and credit teams actually use to make a decision — extend more credit, hold an order, escalate to legal — so it needs to combine things Acumatica tracks in separate places: the credit limit and terms on the Customer screen, the current AR exposure including unbilled shipments, payment history trend, and any open cases or holds. None of that lives in one table, and stitching it together is the whole report.

Exposure is bigger than the AR balance

The naive version of this report sums open AR balance and compares it to the credit limit on Customer.CreditLimit. That understates real exposure for any customer with orders shipped but not yet invoiced, or sales orders booked but not shipped, both of which represent real credit risk the business has already taken on. A proper exposure figure needs three components summed: released AR balance, unbilled shipments (SOShipment where Invoiced = False, valued at the order price), and optionally open order backlog if the business wants to see committed-but-not-shipped exposure too. Ask the credit team which of these they actually want included — showing all three by default with subtotals per component is safer than picking one and being wrong for their process.

SCHEMA — THREE EXPOSURE COMPONENTS, ONE CUSTOMER ROW
ARBalance:     SUM(ARInvoice.CuryDocBal)   WHERE Released=True, CuryDocBal<>0
UnbilledShip:  SUM(SOShipment.CuryOrderQty * unit price) WHERE Invoiced=False
OpenOrders:    SUM(SOOrder.CuryOrderTotal - CuryLineTotalBilled) WHERE Completed=False
Total Exposure = ARBalance + UnbilledShip + (OpenOrders if included)

A snapshot number without trend hides the real signal

A customer sitting at 95% of credit limit today could be a stable pattern (they always run close to the line and always pay on time) or the first sign of trouble (exposure climbing steadily over three months while days-to-pay also climbs). Credit teams read trend, not snapshot. That means the report needs a small trailing series — exposure and average days-to-pay for each of the last 6 periods — which is a group-by-period aggregate over the same AR history, not an additional live join. Compute it once per customer as a period-grouped subquery or a small pre-aggregated projection rather than a subreport invoked per customer; a subreport per customer for six periods of history is exactly the N+1 pattern that turns a 50-customer report into a slow one.

Credit hold status can be stale if you read it from the wrong place

Credit holds in Acumatica can be applied automatically (credit limit exceeded, over terms) or manually by a credit manager. If your report reads only the automatic hold flag and ignores manual holds or hold override notes, credit staff will see a customer as "clear" that their own colleague flagged yesterday. Pull hold status and any override reason text from the same screen users manage it on, not a cached or derived flag.

Wrapping up

Credit exposure is AR balance plus unbilled shipments plus, often, open order backlog — not just the AR aging total. Give credit teams a trend, not a snapshot, computed as a grouped aggregate rather than a per-customer subreport, and read hold status from the live source so a manual override never goes unseen. The report earns its place on someone's daily screen only if the number it shows is the number they'd get manually digging through three other screens.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.