Ask a manufacturing CFO why days sales outstanding is high and the answer is usually about customers who pay late. Walk the order-to-cash process and a different picture appears. The purchase order sat in a mailbox for two days. The despatch went out on Thursday and the invoice on the following Tuesday. The customer's portal rejected the invoice over a line item code. The payment arrived with a remittance advice nobody reconciled for a week. Each delay is small. Together they add weeks to the cash cycle, and every one is a step a bot or an integration can take over.
Where the days go.
DSO is the sum of the time between each hand-off in the cycle, plus the customer's payment terms. Automation cannot change the terms. It can remove nearly everything else.
| Stage | Where the delay sits | What automation does |
|---|---|---|
| Order entry | POs keyed by hand from PDF or email. | IDP reads the PO, validates it, creates the sales order. |
| Credit check | Orders wait for a credit controller. | Rules clear orders within limit and route the rest. |
| Despatch to invoice | Invoicing runs in a batch when someone has time. | An event-driven trigger raises the invoice on despatch confirmation. |
| Invoice delivery | Portals and e-invoice formats handled manually. | Bots submit to portals, rejections return as work items. |
| Cash application | Remittances in a dozen formats, matched by hand. | IDP extracts the remittance, a bot matches and posts. |
| Collections | Reminders go out when the collector gets to the account. | Scheduled dunning by ageing bucket, disputes separated. |
Order entry: stop keying the purchase order.
Most manufacturers receive orders as documents. A document processing model reads the PO, extracts header and lines, and checks each line against the item master, the contracted price and any open quotation. Clean orders become sales orders in the ERP straight through. Mismatches on price, quantity or part number go to a sales coordinator with the PO image and the discrepancy highlighted. Set confidence thresholds by field with the order desk. Part numbers deserve a stricter threshold than a delivery address.
Despatch to invoice: make it an event.
The gap between goods leaving the dock and the invoice reaching the customer is the easiest DSO win in the whole cycle, and the one most often ignored. The despatch confirmation in the ERP or the warehouse system is the trigger. The bot raises the invoice, attaches the proof of delivery, applies the e-invoicing step the customer's jurisdiction requires, and sends it through the channel the customer accepts. An invoice that cannot be raised because a tax code is missing is a business exception. It should reach someone within the hour, and never wait for month end.
- Portal submissions are bot work. Many large buyers accept invoices only through supplier portals. An unattended bot submits with its own service account and stores the acknowledgement number on the invoice.
- Rejections are work queue items. A portal rejection is a transaction item with a reason code, routed to the person who can fix it, retried once corrected.
- Keep the proof of delivery attached. A signed POD on the invoice removes the most common reason for a payment hold.
Cash application: match the remittance, not the bank line.
Payments arrive as a lump sum against several invoices, with short payments, deductions for damaged goods and discounts taken whether or not they were earned. The remittance advice explains all of it, and it arrives as an email body, a PDF, a spreadsheet or a portal download. IDP reads the advice. A bot matches each line to an open invoice, posts clean matches, and raises a deduction case for each short payment with the customer's stated reason. Unmatched amounts go to a queue with the bank line, the candidate invoices and the remittance side by side, so the accountant decides in one screen.
Collections and disputes: separate the two.
A customer who has not paid because the goods were short is a dispute. A customer who has not paid because the invoice is in a queue is a collections case. Treating both the same wastes the collector's time and annoys the customer. Scheduled dunning handles the second group: reminders by ageing bucket, with the invoice and POD attached, escalating on the timetable the credit policy defines. Disputes go to the owning function with the deduction evidence and are tracked to resolution. An agent can draft the dunning message from the case record, with a human approving anything sent to a strategic account.
Controls finance will ask about.
- Credit limit overrides stay with a named credit controller. The bot clears within limit and never raises it.
- Invoice numbering, tax determination and e-invoicing registration happen in the ERP. No invoice is composed outside the system of record.
- Every automated posting carries the source document, the matching rule version and the confidence score, so an auditor can trace a receipt back to a remittance line.
- Deduction write-offs above a threshold need maker-checker approval, with the bot as maker only.
- Bot service accounts are scoped to the transactions in the process definition document.
Sequencing the programme.
Start with despatch-to-invoice and cash application. Both are contained, both are measurable in days, and both free the credit team to chase the accounts that need chasing. Order entry follows once the item master and price lists are clean enough to validate against. Collections comes last, because it works best when the invoices it chases are already correct, delivered and matched. Done in that order, the improvement in DSO is typically visible within the first quarter, and it comes from the process rather than from pressure on customers.
Days sales outstanding is a process measurement wearing a finance label.
If your order-to-cash cycle has more hand-offs than it should, we are glad to walk it with your finance and operations teams and show where the days go.