What happens to mail that is not a claim?

It is classified as a non-claim and reported as one. The intake split — total mail against claims against what reached the system of record — is part of the standard reporting, because a process that silently drops mail it does not recognise is worse than one that never read the mailbox at all.

How do you handle a claim with no attachment?

It is read from the mail body. A meaningful share of claims arrive that way, and treating them as invalid would push the highest-friction cases back onto the team the automation is meant to relieve. The same seven-point gate and the same extraction rules apply.

What happens when a vendor resends a claim with a different amount?

It is checked against the system of record before it is treated as new. If the period is still open the new amount is taken. If the period has lapsed, the account manager or business finance must confirm the amount to be recognised. A change to value, quantity or duration cancels the original and re-raises it.

Can our account managers raise claims on a vendor's behalf?

Yes, and those claims run a negative-confirmation approval loop back to the vendor. Reporting records whether a claim originated with the vendor or with the account manager, so the two populations can be reviewed separately.

Does this replace our claims system?

No. It sits in front of it. Claims are posted into your existing system of record over its API, under your access controls, and the audit trail points back to the mail each claim came from. There is no second claims database to keep in step.

← All solutions

Solutions

Claims that arrive as email and leave as posted records

A dedicated mailbox reads every vendor funding claim, puts it through a seven-point gate before anything is extracted, resolves the products to catalogue codes, posts what passes and tells both the vendor and the account manager what happened.

Book a demo

Seven-point validation gateCatalogue resolution by vector searchRevisions and duplicates handled

Days → minutes

Claim receipt to system entry

The punching queue between an email arriving and the claim existing in the system of record is gone.

100%

Claims validated before entry

Nothing is extracted, let alone posted, until it has cleared every check in the gate.

Business units in scope

Each with its own templates, vendors and account managers, running through one mailbox.

Zero

Manual data entry

People review outcomes and approve exceptions; nobody re-keys a claim.

Vendor programmes

RetailConsumer goodsAgentic workflowERP write-backAudit trail

The challenge

Vendor funding claims arrived as email at a large domestic e-commerce marketplace. Some came on the standard template, dozens more on brand-specific variants, and a share as plain mail with the claim written into the body and no attachment at all. Every one of them was read by a person and re-keyed into the claims system of record. The punching lag delayed collection, claims that slipped past their period landed on the P&L, and vendors had no view of where a submission stood — so the follow-up arrived as another email into the same queue. Across six business units the volume was steady enough that a backlog was not the exception; it was the normal state of the mailbox.

What we built

A dedicated mailbox that reads, checks, extracts and posts on its own. Every submission clears a seven-point gate before extraction begins: sender identity, the correct recipient address, an accepted file format, the template structure, a valid vendor ID, the required confirmation wording, and the vendor's presence on the master mailing list. Agents then normalise what arrives — dates written dd-mm-yy against mm-dd-yyyy, headings written "Vendor Name" against "VendorName" against "vendor", company suffixes and stray symbols — into one internal data model. Products are resolved to catalogue codes by vector search over the embedded product master, including expanding an offer across every colour variant where the template names only the model. Validated claims post over API.

The result

Claims reach the system of record in minutes rather than days, and nothing is entered that has not been validated first. A technical failure is logged and alerted to engineering and the account manager with the API error attached, rather than retried into silence. Outcomes mail back to both the vendor and the account manager with the claim ID, and on a rejection the reason and the action required, so the next mail is a corrected claim rather than a status question. Manual data entry is out of the path across all six business units, and the reasons claims fail are counted by cause rather than argued about.

Process

How it works

Six stages between an email landing in the mailbox and the vendor being told what happened to it. A claim only moves forward once the stage before it has passed.

01
Ingest
The mailbox is read on a schedule. Mail is classified as a claim on the standard template, a claim on a brand-specific template, a claim written into the body with no attachment, or not a claim at all — and the total is reconciled against what reached the system of record, so nothing quietly disappears between the two.
02
Validate
Seven checks run before a single field is extracted: sender identity, correct recipient address, accepted file format, template structure, valid vendor ID, the required confirmation wording, and the vendor's presence on the master mailing list. A submission that fails any of them is held with the failed check named rather than pushed downstream to break later.
03
Extract
Fields are read out of the attachment or out of the mail body itself, then normalised into one internal data model. Dates in conflicting formats, column headings written three different ways, company suffixes and stray symbols are all resolved on the way in, so what follows compares values rather than formats.
04
Resolve
Products named in the claim are resolved to catalogue codes by vector search over the embedded product master, which tolerates the abbreviations and partial descriptions vendors actually write. Where a template names only a model and the offer covers every colour, the offer is expanded across the variants rather than posted against one of them.
05
Post
Validated claims are posted to the system of record over API. A technical failure is not retried into silence: it is logged and alerted to engineering and to the account manager with the API error attached, so a claim that did not land is a known item with an owner rather than a gap found at period end.
06
Notify
The outcome mails back to the vendor and to the account manager with the claim ID. A rejection carries the reason and the action required, which turns the reply into a corrected claim instead of a question about status — and takes the follow-up traffic out of the mailbox that the automation is reading.

What it does

Inside the solution

One mailbox, every format vendors use

The standard template, dozens of brand-specific ones, and mail with the claim in the body and nothing attached. All three are claims, so all three are read rather than bounced back with a request to use the right form.

A seven-point gate before extraction

Sender identity, recipient address, file format, template structure, vendor ID, confirmation wording and presence on the master mailing list. Validation runs first because extracting a claim that should never have been accepted only moves the problem later in the process.

Normalisation into one data model

Dates written dd-mm-yy against mm-dd-yyyy, headings written "Vendor Name" against "VendorName" against "vendor", company suffixes and stray symbols. Everything is mapped to one internal structure, so downstream logic is written once instead of per template.

Catalogue resolution by vector search

Products are matched to catalogue codes by vector search over the embedded product master rather than by exact string match, so a shortened or partial description resolves to the right code instead of stalling the claim.

Offers expanded across variants

Where a template names a model and the offer applies to every colour it ships in, the claim is expanded across the variants. A vendor writing one line does not mean the claim covers one product.

Posting, with failures alerted rather than swallowed

Validated claims post over the system-of-record API. A technical failure is logged and alerted to engineering and the account manager with the API error attached, because a silent retry loop is how a claim goes missing without anyone knowing.

Outcomes mailed to both sides

The vendor and the account manager both receive the outcome with the claim ID. On a rejection they also receive the reason and the action required, so the vendor can correct and resubmit without opening a thread.

Business-unit scoping and audit trail

Six business units run through the same mailbox with their own templates, vendors and approvers, and access follows the unit. Every claim keeps the mail it came from, the checks it cleared and the response it produced.

DESIGN PRINCIPLE

The hard part: revisions

Most claim automation works until a vendor sends the same claim again with a different number. Whether that is a correction, a second claim or an attempt to claim twice is a question about periods and approvals, not about reading a document, and it is where an unattended process either holds up or quietly creates duplicates.

Duplicates are checked against the system of record: Before anything is treated as new, the submission is checked against what already exists. A claim that has been seen is a revision to be reasoned about, not a fresh record to be created alongside the original.
An open period takes the new amount: Where the period the claim covers is still open, the revised amount is taken directly. There is nothing to unwind and no recognition already made, so the correction is simply the current figure.
A lapsed period needs a person to confirm: Where the period has closed, the revision needs specific confirmation from the account manager or business finance on the amount to be recognised. The automation stops and asks rather than deciding what a closed month should now say.
Value, quantity or duration cancels and re-raises: A change to any of the three cancels the original claim and raises a new one, so the trail shows what was claimed and what replaced it. A cancellation after month end is logged as such rather than absorbed.
Claims raised on a vendor's behalf keep the vendor in the loop: Where an account manager raises a claim for a vendor, a negative-confirmation approval loop runs to the vendor. Oversight that existed because a person handled every claim survives the automation instead of being lost to it.

REPORTING

What the team sees

An unattended process is only trustworthy if the people accountable for it can see what it did. Reporting is scoped by role and by business unit, and is built around the questions a claims team and its finance partner actually ask at the end of a week.

Dashboards with trend deltas: Claim volume, value and outcome by business unit, shown against the previous period rather than as a standing total, so a change in behaviour is visible without anyone exporting the underlying data.
Problem areas, counted by cause: Punching failures grouped by the check that failed. A count by cause turns a backlog into a list of fixable things — a vendor off the mailing list, a template that changed — rather than a general complaint about quality.
Intake classification: Total mail split into claims and non-claims, with what reached the system of record tracked against what arrived. The two numbers are reconciled, so nothing is lost between the mailbox and the ledger.
Change-log reporting: Original claim detail shown beside the edited data, so an amendment is visible as a before and an after rather than as a record that simply reads differently than it used to.
Approvals and rejections: Vendor confirmations captured against the claim, along with whether the claim originated with the vendor or with the account manager — the distinction that decides which approval path it should have taken.

Foundations

The VapusFin models behind it

Vendor Claims & Offers

Claims & Offers

Vendor-side money you are owed: rebates, volume credits and early-payment offers, each tied to the contract clause that entitles you to it and filed before it expires.

Details

Accounts Payable Automation

Accounts Payable

Capture every invoice however it arrives, match it line by line against the PO and the goods receipt, and pay only what the contract says you owe.

Details

Questions

Frequently asked

What happens to mail that is not a claim?: It is classified as a non-claim and reported as one. The intake split — total mail against claims against what reached the system of record — is part of the standard reporting, because a process that silently drops mail it does not recognise is worse than one that never read the mailbox at all.
How do you handle a claim with no attachment?: It is read from the mail body. A meaningful share of claims arrive that way, and treating them as invalid would push the highest-friction cases back onto the team the automation is meant to relieve. The same seven-point gate and the same extraction rules apply.
What stops a bad claim from entering the system of record?: Extraction does not begin until the submission has cleared every check in the gate: sender, recipient address, file format, template structure, vendor ID, confirmation wording and mailing-list membership. A failure is held with the failed check named, so the vendor is told what to fix.
What happens when a vendor resends a claim with a different amount?: It is checked against the system of record before it is treated as new. If the period is still open the new amount is taken. If the period has lapsed, the account manager or business finance must confirm the amount to be recognised. A change to value, quantity or duration cancels the original and re-raises it.
Can our account managers raise claims on a vendor's behalf?: Yes, and those claims run a negative-confirmation approval loop back to the vendor. Reporting records whether a claim originated with the vendor or with the account manager, so the two populations can be reviewed separately.
Does this replace our claims system?: No. It sits in front of it. Claims are posted into your existing system of record over its API, under your access controls, and the audit trail points back to the mail each claim came from. There is no second claims database to keep in step.

Want the same outcome?

Point us at a month of your claims mailbox — templates, brand variants and body-only mail included — and we will show you what would have validated, what would have been held and why, before you commit to anything.

Book a demo

Last reviewed 4 September 2026

Claims that arrive as email and leave as posted records

The challenge

What we built

The result

How it works

Ingest

Validate

Extract

Resolve

Post

Notify