Credit Control and Collections Management

An ageing report tells you who owes you money. It does not tell you who to call today, what they promised last time, whether their next order should ship, or whether a balance is genuinely overdue or sitting behind a delivery dispute nobody logged. Most SAP Business One companies have all the data a collections function needs and no process on top of it: the ageing is exported every Monday, three people work from three copies of it, and the only escalation is a phone call from the finance director at month end.

SAP Business One gives you the primitives, and they are worth being honest about. A Business Partner carries a credit limit and a commitment limit, deviation behaviour can warn or block, and the Dunning Wizard produces a batch of letters against dunning terms and levels. Used well, that is a limit check and a mail merge. It is not credit management. The limit check looks at the receivable balance and not at the undelivered order book behind it. There is no risk assessment, no record of who released a held order and why, no work queue, no promise-to-pay, and no way to keep a disputed line out of the dunning run.

This extension puts the process on top of the data, inside SAP Business One, so that credit decisions are recorded, exposure is complete, collectors work from one prioritised queue, and the ageing stops being the output of the function and becomes an input to it.

What ECOSIRE builds

This is a build-to-order extension. Nothing is pre-built and there is no instant download: we scope your credit policy, your blocking appetite, your dunning ladder and your collections team structure, quote it at a fixed price, then build it for your company and install it into your test company database before production. A standard scope is one working week from signed quote to test install.

The deliverable is a SAP Business One add-on. Logic and document access run through the Service Layer (REST/OData), with the DI API used where a client-side add-on component is required. Credit files, scores, promises, disputes and dunning history live in User-Defined Objects and User-Defined Tables; additional fields on Business Partners and marketing documents are User-Defined Fields. Where a hard block must be enforced at database level we use the documented SBO_SP_TransactionNotification extension point, and we keep that surface as small as possible so upgrades stay clean. It targets SAP Business One 10.0 on Microsoft SQL Server and on SAP HANA, on-premise or cloud-hosted.

The credit file and the decision trail

Each customer gets a credit file as a User-Defined Object: requested limit, approved limit, effective and review dates, security or guarantees held, credit insurance cover and its excess, trade references, and the reasoning behind every change. A limit is no longer a number somebody typed into a Business Partner master with no history — each version records who approved it, on what evidence, and when it is next due for review. Review dates drive a work list, so limits set two years ago stop being treated as current.

Risk scoring from behaviour you already have

The score is computed from your own transaction history rather than from an opinion: measured days beyond terms across A/R Invoices and Incoming Payments, days sales outstanding trend, largest balance ever carried, returned or failed payments, broken promises, disputed proportion of the balance, order-book concentration and account age. Weightings are yours to set, bands are yours to name, and the score is recalculated on a schedule with the inputs shown so a collector can see why an account moved band.

Exposure that reflects the whole pipeline

Exposure is calculated as more than the open receivable: unpaid A/R Invoices, undelivered Sales Order value, Deliveries not yet invoiced, issued A/R Down Payment requests and, optionally, unbilled project work in progress. This is the single change that most often surprises a first-time user, because an account comfortably inside its limit on the ageing is frequently well outside it once the order book is counted.

Blocking that the sales team can live with

Rules are evaluated when a Sales Order or Delivery is added, with distinct configurable behaviour per risk band and per exposure threshold: warn and continue, hold for release, or hard block. A held document is released through a SAP Business One approval procedure by a named approver with a reason code — never by quietly editing the limit, which is how most credit policies actually die. Every block, release and override is stored against the document and the customer. We normally recommend starting in warn-only mode for a period so the policy is calibrated against real order flow before anything is stopped.

The collections work queue

Accounts are assigned to collectors as portfolios and presented as a prioritised queue ordered by weighted overdue value, risk band and next action date, not alphabetically. Each row opens the full account picture: ageing, exposure, recent documents, contact history, open disputes, live promises and the last dunning level reached. Every call, email and visit is written as an Activity against the Business Partner, so the collections history sits in the standard SAP Business One timeline where the account manager can see it too.

Promise-to-pay

A promise is recorded with amount, promised date, method and reference, and is then reconciled automatically against Incoming Payments and marked kept, partial or broken. Broken promises feed the risk score, escalate the dunning level and reappear in the queue on the day they fail. This is the mechanism that separates a collections process from a call log.

Dunning as a ladder, not a batch

Dunning levels are driven by days overdue, exposure and risk band together, each with its own template, tone, channel and waiting period before escalation. Letters and statements are Crystal Reports layouts in your branding and languages, emailed with the relevant A/R Invoice copies attached, and every send is logged against the customer with the level and the document set included. Suppression is explicit and fails safe: accounts on an agreed payment plan, in dispute, in legal process or flagged on hold are excluded from the run rather than relying on somebody remembering.

Disputes, deductions and reporting

A disputed amount is recorded with a reason code and an owning department, excluded from the dunning base and from collectable-cash reporting until resolved, and aged separately so long-running disputes become visible. Reporting covers the ageing bridge period on period, days sales outstanding and best-possible days sales outstanding, collector performance, promise-kept rate, blocked-order value, dispute ageing by reason, and a weighted collectable-cash figure that can feed a cash forecast.

Who this is for

Distributors, manufacturers, contractors and service businesses selling on credit at enough volume that receivables need a team rather than a person. The usual triggers are a growing overdue balance nobody owns, an order-release argument between sales and finance every week, a bad debt that surprised everybody, or a lender asking for days sales outstanding you cannot evidence.

How delivery works

1. Scoping call. We work through your credit policy, limit authorities, blocking appetite, exposure definition, dunning ladder, languages, collector structure and reporting needs, and confirm your version, database platform and hosting arrangement. 2. Fixed quote against a written specification. Rules, scores, screens, letters and reports are listed, along with what is out of scope. 3. Build. Development against a copy of your company database, so the first risk scores and exposure figures you review are your own customers. 4. Install into your test company. Objects, fields, blocking hooks, approval procedures, letter layouts and dashboards deployed, with opening promises and disputes loaded if you already track them. 5. Warn-only calibration. The policy runs without stopping anything while you compare what would have been blocked against what should have been. 6. Production install and enforcement. Enforcement enabled band by band, with a documented rollback path. 7. Support window. Defect fixes plus one calibration round on the risk score and dunning ladder after your first full dunning cycle.

After go-live

You keep the configuration workbook recording every rule as delivered, a named support contact, and retesting against your next SAP Business One patch or upgrade during the support window. Later changes — a new dunning level, another language, a revised exposure definition, an extra collector portfolio — are configuration or small quoted changes against the same specification.