· Rakesh Gangwar
Automating invoice factoring often starts with document extraction. Read the invoice, identify the seller and buyer, find the amount and due date, and compare those fields with the supporting evidence.
That removes data entry. It does not resolve the case that needs judgment.
The difficult file is the one where the invoice and delivery evidence agree, but funding it would take the buyer’s aggregate exposure beyond an approved limit. Or the invoice may match the buyer record while a required document is still missing. These are not extraction failures. They are exception conditions that require evidence, policy, and an authorised decision.
The case below is illustrative. The exact documents, roles, and policy rules vary between factoring businesses. The shape of the exception is what matters.
The exception starts before the credit decision
An invoice arrives with the evidence the factoring business requires. The intake step checks what was received, whether the invoice has already appeared, and what is still required.
At the same time, the process looks up the seller and buyer through the systems already holding those records. It retrieves the buyer’s current exposure and approved limit, along with the values needed for the policy check, and records where each value came from. If funding the invoice would cross that limit, if a possible duplicate submission is found, or if two systems disagree, the condition becomes a named exception rather than an empty cell someone notices later.
None of this requires the process to make a credit decision. It requires the process to gather the material on which that decision depends.
In a manual exception path, the analyst is usually the integration layer. They open the document store, the operational system, the policy file, and email. The work moves only while they are holding all of it in their head.
Missing evidence should create a wait, not a loose end
Suppose proof of delivery is missing and has to come from the seller or a relationship manager. The process can send the request, record what it is waiting for, and pause the case.
When the document arrives, the same run should resume with the state it already had. The buyer lookup does not need to be rediscovered. The earlier checks do not need to be repeated unless policy says they have gone stale. The analyst does not need a reminder to search an inbox and reopen the case.
This is a small design choice with a large operational consequence. Waiting is part of the process. If it exists only in somebody’s inbox or task list, the person is still carrying the process.
Put policy in a decision model, not in the extraction prompt
Once the evidence is complete, the process can evaluate the applicable policy.
The rules might consider whether required evidence is present, whether the invoice appears to be a duplicate submission, whether buyer exposure crosses an obligor limit, whether concentration exposure crosses a portfolio boundary, or whether the combination of conditions requires another level of review. The exact rules belong to the business. They should be readable, versioned, and testable as policy.
This is different from asking a model to read a policy document and decide what it means on every run. A model can help classify an unstructured document or explain an ambiguity. A deterministic rule should still remain deterministic. The process should know which policy version produced the result.
In Superprocess, business rules run as versioned DMN decision models. The model step and the policy step are separate participants in the process. Changing a threshold does not require rewriting the prompt that extracts or interprets the documents.
The system can prepare the decision without owning it
At this point the process has assembled the documents, retrieved the system records, applied the policy, and identified the exception. An AI worker may summarise the case and produce a recommendation within the tools and boundaries declared for that step.
Then it stops.
The reviewer receives a specific decision—such as whether to approve an exposure exception—the reason the case was escalated, the source evidence, the policy result, and the proposed next action. The person with the required authority approves, rejects, or asks for more evidence.
That is not partial automation. It is a deliberate division of work. The software does the carrying. The authorised person makes the material credit decision.
Trying to maximise straight-through processing can obscure this distinction. The better target is to minimise the amount of reconstruction required before a person can exercise judgment.
The escalation path should also be allowed to say that the policy is incomplete. Some cases do not need a more capable model or another retry. They expose a condition the written rules do not cover. The reviewer can decide the case under the organisation’s existing authority, record why, and send the policy question back to its owner. Treating that response as process data is more useful than quietly adding another instruction to a prompt. It makes the edge case visible, reviewable, and available when the next similar invoice arrives.
The record should be produced while the case runs
After the decision, the process writes the result to the appropriate system and continues along the approved path. It also retains the history needed to answer what happened later: which inputs were used, which policy version applied, what the system recommended, who approved it, and what rationale they recorded.
That record is difficult to recreate from a database row and an email thread. It is straightforward when each action is already part of the same process run.
This is the exception path worth automating in invoice factoring. Not because the final decision is unimportant, but because it is important enough that the reviewer should spend their time deciding rather than collecting.
The useful boundary is therefore not automation versus human work. It is the boundary between carrying the file and owning the credit decision.