Funding decision and cash application

Screen, verify, calculate the advance, then apply the payment back to the invoices it settled

• Domain: Finance & Accounting
• Moment: Before the money moves
• Customer: An invoice factoring company funding receivables against a rolling client book

Check eligibility, duplicates, and the advance before funding.

The situation

A factoring company advances cash against receivables. Money leaves on the strength of a document, weeks before the debtor pays. Speed is the product, so the decision is made under pressure.

Two decisions sit on every invoice: whether to fund it, and how much. Weeks later a payment arrives covering several invoices at once, for an amount that matches none of them, and it has to be applied back.

What breaks today

Eligibility depends on a manual checklist. The reviewer checks debtor status, limit headroom, age, concentration, and exclusions for every invoice under time pressure.

The same invoice can be presented twice. Resubmitted under a slightly different number, or presented again after a credit note reversed it. A near-duplicate differing by one character defeats an exact-match check and is never seen by a human.

Verification stays in a message thread. Confirmation can arrive by email, portal, phone, or delivery document. The next reviewer has to search the conversation to learn who verified it and when.

The calculation is rebuilt every time. Advance rate by client and sometimes by debtor, chargebacks from a prior period, fees accrued and not collected, assembled in a spreadsheet. Months later, defending that rate means rebuilding it from an inbox and somebody's memory.

The remittance does not name the invoices. One payment covers many. The debtor takes a settlement discount, deducts a short-ship claim, or lets the bank charge come off the top. Nothing matches exactly, and the remainder ages in suspense with no reason recorded.

What Manuel does

Stage 1, eligibility across the whole submission. Every invoice in a schedule is checked against the rules as approved and versioned: debtor status, limit headroom, age against terms, concentration, exclusions. Each check returns pass, fail or needs review, naming the rule and the value that triggered it.

Stage 2, duplicates and disputes. Match on invoice number, then debtor, amount, and date, followed by normalised text for small edits. A confirmed duplicate or dispute stops the funding. AI can raise a possible issue, while a versioned rule determines the result.

Stage 3, verification held as a field. Whichever channel the confirmation arrives through, it is captured against the invoice: who confirmed, when, through which channel, with the document kept as evidence. An unverified invoice cannot enter the calculation.

Stage 4, the advance calculated once and shown in full.

net advance = (eligible invoice total x advance rate)
              - chargebacks
              - fees due

Every term traces to its inputs: which invoices formed the eligible total, which were excluded and why, which rate version applied, and which chargebacks and fees were carried. The number and calculation are stored together so another reviewer can repeat the decision.

Stage 5, cash applied back to the invoice. Matching runs as a stated rule set: remittance reference first, then debtor plus exact amount, then the one-to-many case where one receipt clears several invoices, then the short payment where the difference equals a known deduction. What remains is a residual queue where every item carries a named shortfall: discount taken, deduction claimed, fee withheld, or unexplained.

AI reads documents, classifies deductions, and proposes a cause for an unexplained residual. Versioned rules decide the advance and record the calculation for later review.

What the customer gets

This is a designed test with no production measurement yet.

The recommendation arrives with supporting records. Duplicate checks run before funding, unapplied cash receives a reason, and approved rules are versioned for the full team.

What we would measure in a paid discovery, on your data: first-pass allocation rate per remittance channel, time from submission to decision, how many invoices reach funding unverified, and the size and age of suspense. Those become the acceptance criteria in the contract.

What stays with your existing systems

Your factoring ledger stays the system of record for the client book, balances and postings. Your credit data source and your bank stay.

Manuel does not hold funds and does not set credit policy. It applies the policy you approved, to every item, and shows its working.

What a first scope looks like

One client portfolio, one quarter of history, files first, read-only.

We re-run eligibility and duplicate detection over invoices you have already funded, and cash application over remittances you have already allocated. That produces the disagreements with your own result, and a documented exception taxonomy for the residual. Manuel makes no funding decision while it runs.

Related: Payment release control on high-risk disbursement / Residual exception diagnosis / Pre-reconciliation detection