Is this accusing our credit control team of something?

No. Most findings turn out to be process problems — a missing dispute record, a receipt applied in a hurry, a customer set up twice. The value is that both explanations become visible, and the innocent one is confirmed rather than assumed.

How do you decide a credit note is unusual?

By comparing it against that customer's own history and against the invoice it offsets, including whether a dispute, return or price correction supports it. A generic threshold would flag every large customer and miss the small, repeated adjustments that matter.

What makes two customer records the same party?

Similarity across name, registration, address and bank details taken together rather than any one of them. The match is proposed with the evidence shown; merging records is a decision your team makes, not one the platform makes for you.

Can it tell a misapplied receipt from a legitimate part payment?

A part payment fits the invoice it was applied to. A misapplication does not fit on amount, date or customer, and it is that mismatch which raises the case. Both records are attached so the reviewer can settle it in one place.

Does it need to write to our ledger?

No. It reads the ledger and raises cases. Corrections are made in your system by your team under your controls, and the case records what was concluded so the trail stays complete.

Has this been delivered for a customer?

Not as a standalone engagement. The matching engine, the exception typing and the case reporting behind it are running in delivered receivables reconciliation work, and these checks are a use of the same components.

← All solutions

Solutions

Receivables leak through adjustments, not through theft

Credit notes that do not fit the customer's pattern, write-offs clustered around one approver, the same customer existing twice under different identities, and receipts applied against invoices they do not belong to — each surfaced with the records behind it.

Book a demo

Credit note and write-off patternsDuplicate customer identitiesMisapplied receipts

Receivables

RetailFinancial servicesFraud & anomalyAgentic workflowAudit trail

The problem

Receivables manipulation looks like ordinary housekeeping. A credit note clears a balance that was never going to be collected. A write-off is approved just under the threshold that would have required a second signature. A customer exists twice, so an aged balance under one identity is settled against the other. A receipt is applied to an invoice it does not belong to, and both accounts look plausible afterwards. Each of these is a normal transaction on its own, and each is only visible as a pattern — across time, across approvers, across the customer master — which is exactly the view a monthly aged-debt report does not provide.

What the platform does

Adjustments are examined as a population rather than one at a time. Credit notes are compared against the customer's own history and against the invoices they offset, so a note without a matching dispute or return stands out. Write-offs are grouped by approver, customer, amount and timing, which surfaces clustering just below an approval threshold. The customer master is checked for duplicated identities using name, registration, address and banking similarity. Cash application is re-tested: a receipt applied against an invoice whose amount, date or customer does not fit is raised, with both the receipt and the invoice attached.

What you get

The adjustments that need explaining are named, and the ones that do not are left alone. A case carries the records that produced it — the credit note and the invoice it offsets, the write-offs clustered under one approver, the two customer records that appear to be one company — so the reviewer starts from evidence rather than from a hunch. Because the checks run against the ledger continuously, a pattern is visible while the parties involved are still available to explain it, and the audit trail of what was reviewed and what was concluded survives the reviewer moving on.

Process

How it works

Four stages. Every one of them compares a transaction against a population rather than against a threshold, because a single adjustment is almost never the evidence.

01
Read the ledger
Invoices, credit notes, receipts, write-offs and the customer master are read together. A receivables case is nearly always a relationship between two of those records, so examining any of them in isolation is what allows the pattern to persist.
02
Test the adjustments
Credit notes and write-offs are compared against the customer's own history and against the invoices they offset. Amount, timing, approver and the presence of a supporting dispute or return are all part of the comparison, so an unexplained adjustment is distinguishable from a routine one.
03
Resolve identities
The customer master is checked for the same party existing more than once under different names, registrations, addresses or bank details. Duplicated identities let a balance move between accounts, and they also inflate every ageing analysis run against the ledger.
04
Re-test cash application
Receipts are re-matched against the invoices they were applied to. Where the amount, date or customer does not fit, the pair is raised as a case with both records attached, since a misapplied receipt leaves two accounts wrong and neither of them obviously so.

What it does

Inside the solution

Credit notes against the customer's pattern

A credit note is read against that customer's own history and against the invoice it offsets. One issued without a matching dispute, return or price correction is the case worth reviewing, and it is not visible in a total.

Write-offs grouped by approver

Write-offs are examined by approver, customer, amount and timing together. Clustering just below an approval threshold is the signature that a single write-off cannot show and a grouped view cannot hide.

Duplicate customer identities

The same party under two records — a variant name, a second registration, a shared address or bank account — is surfaced. Duplicated identities allow balances to be moved between accounts and distort every ageing report built on the master.

Misapplied receipts

Cash application is re-tested against the invoices it claims to settle. A receipt applied where the amount, date or customer does not fit is raised with both records attached, because it leaves two accounts wrong in offsetting directions.

Deduction and short-payment patterns

Repeated short payments and deductions are grouped by customer and reason rather than absorbed one invoice at a time, so a customer systematically deducting the same amount is identifiable as a pattern rather than a series of small write-offs.

Cases, not alerts

Each finding arrives as a case carrying the records that produced it. A reviewer opens the evidence rather than a score, which is the difference between a control people use and one they learn to dismiss.

Continuous rather than periodic

Checks run against the ledger as it moves rather than at month end, so a pattern is raised while the people who can explain it are still involved with the account.

Reviewed, concluded, retained

What was reviewed, by whom, and what was concluded is retained with the case. The record outlasts the reviewer, which is what makes the same question answerable the next time it is asked.

Foundations

The VapusFin models behind it

Fraud & Anomaly Detection

Fraud & anomaly detection

Vendors, buyers, orders, payments and transaction patterns connected across payables, receivables and distribution networks, so suspicious activity is exposed across entities, channels and geographies before it becomes a financial or compliance problem.

Details

Accounts Receivable Automation

Accounts Receivable

Apply cash the day it arrives, classify every short payment and deduction, and chase the invoices most likely to be collected first.

Details

Questions

Frequently asked

Is this accusing our credit control team of something?: No. Most findings turn out to be process problems — a missing dispute record, a receipt applied in a hurry, a customer set up twice. The value is that both explanations become visible, and the innocent one is confirmed rather than assumed.
How do you decide a credit note is unusual?: By comparing it against that customer's own history and against the invoice it offsets, including whether a dispute, return or price correction supports it. A generic threshold would flag every large customer and miss the small, repeated adjustments that matter.
What makes two customer records the same party?: Similarity across name, registration, address and bank details taken together rather than any one of them. The match is proposed with the evidence shown; merging records is a decision your team makes, not one the platform makes for you.
Can it tell a misapplied receipt from a legitimate part payment?: A part payment fits the invoice it was applied to. A misapplication does not fit on amount, date or customer, and it is that mismatch which raises the case. Both records are attached so the reviewer can settle it in one place.
Does it need to write to our ledger?: No. It reads the ledger and raises cases. Corrections are made in your system by your team under your controls, and the case records what was concluded so the trail stays complete.
Has this been delivered for a customer?: Not as a standalone engagement. The matching engine, the exception typing and the case reporting behind it are running in delivered receivables reconciliation work, and these checks are a use of the same components.

See it against your own ledger

Give us a period of invoices, receipts, credit notes and write-offs and we will show you the cases it raises and the records behind each one.

Book a demo

Last reviewed 4 September 2026

Receivables leak through adjustments, not through theft

The problem

What the platform does

What you get

How it works

Read the ledger

Test the adjustments

Resolve identities

Re-test cash application

Inside the solution