.png)
IN SHORT
A delivery can be operationally complete while billing is missing, incomplete or late. A billing completeness control compares delivery status, billing relevance and document flow against the expected billing window. Relevant exceptions can then be prioritized by unbilled amount, assigned to the responsible organization and documented through to resolution.
Delivered is not the same as billed.
Operationally, the process can look finished. Goods issue is posted, the customer has received the goods and the delivery is closed. Financially, the process is still open because the invoice is missing, incomplete or created later than intended. Until billing happens, collection cannot start as intended.
On day three, nobody would call this a problem. The billing document is created, the customer pays on the agreed terms and the case disappears.
Four months later, the same case can take a morning to reconstruct. The contact person on the customer side may have changed. The delivery note has to be found. Quantity or price gets disputed, the period is closed, and suddenly a credit memo is part of the conversation. The amount may still be recoverable. The date on which you expected the cash is not.
That is the argument for treating billing completeness as a recurring control rather than an occasional clean-up exercise.
Often there was a perfectly reasonable reason at the start. The problem is that the exception can remain after that reason has disappeared.
Most of these are not dramatic control failures. They are ordinary process exceptions that were never brought back into view after the original reason had passed. Together they form exactly the population a recurring control should look at.
Quite a lot, actually. The billing due list shows what is waiting to be billed, and document flow shows what happened to a delivery. Reporting can be built on both, and many teams work exactly this way and do it well.
The gap often appears in the follow-up. Someone opens the list, filters it, compares cases with the expected billing process and involves colleagues from different organizations. The cases that remain then need an owner, a decision and evidence of what happened next.
Automated monitoring picks up there. It does not replace the billing due list; it takes over the recurring analysis around defined exceptions and makes the follow-up easier to trace.
Learn how remQ provides comprehensive business transaction monitoring, internal controls automation, and compliance management. Your data stays where it belongs – securely within your SAP environment.
Consider a delivery worth EUR 125,000. Goods issue is posted on day zero and billing is expected within five days. On day 45, there is still no complete invoice, so the value has not entered the collection process as intended.
The 45 days illustrate the business impact, not a fixed control rule. A company that bills daily may treat five days as an exception; a monthly billing process will use a different threshold. The control should follow the expected billing process, not an arbitrary number from an example.
Nothing exotic. It is the information a reviewer would otherwise collect by hand:
Every billing control has legitimate exceptions: consignment, intercompany flows, free-of-charge deliveries, samples, milestone billing or certain project structures. These can all produce deliveries that should not be invoiced in the usual way.
If legitimate exceptions appear every month, users will stop trusting the result. In many cases, the problem is not the threshold but the scope.
Define the exclusions deliberately, for example by document type, item category, billing relevance, customer group or organizational unit. Write them down once. A documented exclusion is part of the control; an undocumented workaround is much harder to explain later.
Four questions should already be answered when the case arrives: What was delivered? What should have been billed? How much is still open? Who is responsible? The reviewer adds the fifth: what should happen next?
The possible decisions are usually unspectacular, and that is the point. Create the missing billing document. Release a block that is no longer valid. Correct a quantity or price and bill the remainder. Confirm that the delivery is not billing relevant and record why. Each is a legitimate outcome, and each should still be understandable a year later without searching through a mailbox.
Once a case has been raised, the review is only part of the job. The decision also needs to remain traceable.
When detection and review happen in the same process, the control history shows which population was analyzed, which parameters applied, when the control ran, which cases were raised and how they were resolved. The reviewer, decision and timing stay with the case instead of being reconstructed later from emails, spreadsheets or screenshots.
For Billing and Accounting, that means less follow-up work. For Internal Controls and Audit, it means the same control can be evidenced consistently across periods and entities.
Start with one well-defined run.
That immediately shows how many deliveries are already beyond the expected billing window, how much value is still unbilled and where those cases sit in the organization.
Before doing that, the scope needs to be sensible: which sales organizations should be included, which document and item types belong in scope, what billing-delay threshold is appropriate, and which legitimate scenarios should be excluded?
These are also the questions covered in an Order-to-Cash Control Automation Assessment. The goal is to define a practical starting point for the first run rather than discuss control automation in the abstract.
remQ: Controls | Compliance | Monitoring provides comprehensive business transaction monitoring, internal controls automation, and compliance management.
.png)
It describes a delivery where goods issue has been posted and the item is billing relevant, but no complete billing document exists. The value has been delivered to the customer but has not yet entered the collection process as intended.
At the next scheduled run after the configured billing-delay threshold has been exceeded. The threshold itself should match the expected billing process, so a daily billing organization can use a much shorter window than a monthly one.
Common causes include billing blocks that were never removed, partial deliveries with only partial billing, changes in organizational responsibility, missing billing-relevant follow-up documents and corrections where the next process step was never completed.
By scoping the control properly. Legitimate scenarios such as consignment, intercompany, free-of-charge deliveries, samples and milestone billing should be excluded using relevant process criteria, and those exclusions should be documented.
Usually Billing, Accounting or Shared Services, with the sales organization involved where a commercial decision is needed. What matters is that the case has a clear owner and that the decision is recorded.
