How to build a payment receipt and collections agent

In 60 seconds: A payment receipt agent is a bounded workflow that receives an image or PDF, preserves the original, extracts candidate fields, queries orders or accounts receivable, and explains why it proposes a match. The ERP or receivables system remains the source of truth. A confidence threshold routes a case, but it does not grant permission. Never post a payment without approved rules, current validations, and the authorization level set by Finance. Illegible files, duplicates, amount mismatches, and cases without an order enter quarantine with evidence and an owner. Test it for two weeks in shadow mode and measure validated auto-match, exceptions, and time to reconciliation before increasing autonomy.

Receipts may arrive through WhatsApp, email, or Teams, but the core work changes little: identify the document, read it, find the correct account, and leave a traceable decision. A common mistake is to start with the channel or model and call a sequence of automations an “agent” without giving it an operating contract.

This playbook starts with that contract. The route for receipts received through WhatsApp covers chat intake. The Outlook and Teams guide develops the Microsoft 365 orchestration. Here, we design the component that both channels feed.

1. Define the objective as verifiable work

A reasonable first release performs five jobs:

1. receive the file and minimum channel context;
2. extract candidate fields without altering the original;
3. look up eligible orders, invoices, or open items;
4. propose a match or flag an exception with a specific reason;
5. prepare the posting payload for review or authorized execution.

“Manage collections” is too broad. It includes follow-up, payment promises, disputes, credit, reconciliation, and decisions this agent should not assume. Write a testable output instead, such as: “create a case with normalized fields, one receivables candidate, and evidence for every rule.”

Limit the pilot to one channel, legal entity, currency, and receipt type. Define what stays outside as well. Partial payments, combinations of several invoices, credit notes, or documents from another subsidiary can begin as exceptions even if they are added later.

2. Assign a source of truth to every datum

Chat or email proves that a file arrived. It does not prove that funds arrived or decide which balance changes. Each component preserves a different part of the state:

Component	Responsibility	It must not become
Chat or email	Channel, permitted identity, message, and receipt time	Collections ledger
Temporary storage	Immutable original, hash, metadata, and retention policy	A folder that decides whether a payment was posted
OCR or vision	Text, candidate fields, and reading evidence	Financial authority
Review queue	Reason, owner, priority, decision, and age	A disconnected second ERP
ERP or accounts receivable	Customer, order/invoice, balance, application, reversal, and official history	A source the agent can rewrite without controls

Use stable identifiers to connect message, file, case, candidate, and transaction. The guide to the cost of copying data between systems helps measure the work that disappears and the work that merely moves to another screen.

3. Design permission and control per action

Assign autonomy action by action because intake, reading, recommendation, and writing carry different risks:

Action	Minimum permission	Recommended starting level	Control
Receive and preserve the file	Read from the channel and write to staging	Bounded execution	Format, size, malware, hash, and retention
Extract fields	Read the working copy	Read	Schema, original values, and field-level confidence
Query orders or receivables	Read-only view with limited fields	Read	Entity, customer, state, currency, and cutoff time
Propose a match	No financial write permission	Recommend	Visible rules, candidates, and differences
Prepare an entry or application	Create a draft without posting	Draft	Fixed payload, current balance, and duplicate check
Post the payment	Specific and revocable operation	Approved execution, if policy permits	Authorized person, segregation of duties, limits, and log

A confidence threshold classifies evidence. It can allow a high-confidence case to reach match_proposed; it should not turn a prediction into financial permission. Immediately before any authorized write, query the balance, state, currency, reference, and duplicates again. If the approved payload has changed, its authorization is no longer valid.

The guide to control levels for AI agents separates reading, recommendation, drafting, and execution. Human review is mandatory for exceptions. For normal cases, the company must still decide whether the agent only prepares the record or may execute within an existing financial control.

4. Choose tools with narrow contracts

Build small operations with inputs and outputs that can be validated instead of granting general desktop access or one generic tool to “use the ERP”:

Tool	Input	Output	Important boundary
ingest_receipt	File and message ID	case_id, hash, and controlled location	Rejects a disallowed format or size
extract_fields	case_id	Amount, currency, dates, reference, identifiers, and field confidence	Does not decide the match or invent missing data
lookup_customer	Normalized identifiers	Customer candidates with internal IDs	The channel display name is not sufficient identity
lookup_receivables	Customer, entity, and approved filters	Eligible orders, invoices, or open items	Read-only, with query time in the result
enqueue_review	Case, reason, evidence, and priority	An item with owner and SLA	Rejects an exception without an enumerated cause
prepare_erp_entry	Candidate and validated fields	Exact draft of the change	Does not post the payment
post_payment	Approved payload and current authorization	ERP ID and response	Only if policy permits; idempotency and logging are mandatory

OCR or document vision can read variable layouts. Deterministic rules should normalize decimals, dates, currency, references, and states. A model may explain a discrepancy or propose candidates when text is ambiguous, but a missing identifier remains missing data, not an invitation to invent it.

5. Model a case before modeling a conversation

At minimum, store:

• case_id, channel, message ID, receipt time, and authorized sender;
• original file name, type, size, and hash;
• amount and original text, normalized amount, and currency;
• operation date kept separate from receipt time;
• original and normalized reference;
• customer and document candidates with stable IDs;
• every rule result, difference, and field-level confidence;
• state, exception reason, owner, and deadline;
• decision, actor, policy version, and destination-system response.

Do not reduce the case to one percentage. An amount may be read perfectly and still belong to another invoice. Extraction quality, match strength, and permission to write are separate evaluations.

6. Build the happy path first

A normal case should be explainable from end to end:

1. The connector receives an image or PDF from a permitted source.
2. Intake creates case_id, calculates the hash, and preserves the original.
3. Extraction returns candidate fields and marks missing or uncertain values.
4. Rules normalize formats without losing the received values.
5. The agent resolves the customer through agreed identifiers.
6. A read-only query retrieves eligible documents from the ERP or receivables system.
7. Matching compares reference, customer, currency, amount, date, state, and duplicates.
8. If one candidate is within policy, the agent presents the evidence and prepares the permitted entry.
9. A final validation checks current data; an authorized person or external control decides the write, and the ERP response is stored.

Use an idempotency key that survives retries. A customer confirmation should depend on a result accepted by the system of record, not on the agent finishing a draft.

7. Treat exceptions as first-class outputs

Quarantine is part of the product. Every entry needs a cause, evidence, owner, and next action:

Exception	Detection	What the reviewer sees	Possible resolution
Illegible	Required fields are missing or an area cannot be read	Original and uncertain fields	Request another file or transcribe under the defined control
Possible duplicate	Hash, reference, or a posted operation matches	Earlier case, amount, date, and state	Confirm the duplicate or justify a separate operation
Amount mismatch	Receipt and balance differ outside policy	Both amounts, currency, and difference	Keep pending, associate under policy, or request clarification
No order or receivable	No eligible candidate exists	Identity, filters, and searches used	Correct identity, match manually, or return to sender
Multiple candidates	More than one document passes the first filter	Short list and field-level differences	Choose with justification or request information
Destination error	ERP rejects or does not confirm the write	Payload, response, and pre-attempt state	Retry idempotently or escalate without duplicating

The reviewer must be able to correct extraction, change the candidate, request clarification, or close the case with a reason. Their decision returns to the case; it cannot remain only in a message. The playbook for moving from cleaning Excel to managing exceptions shows how to make these corrections an operational queue instead of invisible cleanup.

8. Preserve evidence, stop controls, and recovery

The record should answer what arrived, what the extractor read, which candidates the ERP returned, which rules passed, what the agent proposed, who decided, and what the system returned. Minimize sensitive data in logs and apply the retention policy to originals, extracted fields, and traces.

Keep the stop control outside the agent’s reasoning. It must block new writes, pause the queue, and support revoking the technical credential. Prepare manual recovery as well: identify the last confirmed transaction, isolate uncertain cases, reconcile against the ERP, and resume without repeating operations.

Test repeated files, duplicate events, OCR outages, stale queries, a balance change between proposal and approval, ERP timeouts, and ambiguous destination responses.

9. Run a two-week pilot

Start in shadow mode. The agent receives, extracts, searches, and proposes while the team keeps its current process. Do not use the pilot to test every channel and document type at once.

Week 1: coverage and rules

• Document a baseline for time to reconciliation, exceptions, and rework.
• Process an authorized, minimized sample; use synthetic documents for development.
• Compare proposed fields and matches with the team’s actual decision.
• Classify every failure as extraction, identity, rules, ERP data, or missing policy.
• Adjust the schema, candidate search, and review card; do not hide errors by moving a threshold without analyzing the cause.

Week 2: operations and recovery

• Open the queue to its owners and measure capacity, age, and resolution.
• Allow drafts only for the scope that worked in shadow mode.
• Test retries, duplicates, stop controls, and recovery with controlled cases.
• Reconcile received cases, accepted proposals, exceptions, and ERP responses.
• Decide whether to continue, revise scope, or keep the process manual.

Metric	Useful definition
Validated auto-match rate	Cases with one candidate confirmed by the team ÷ eligible received cases
Exception rate	Quarantined cases ÷ received cases, segmented by cause
Time to reconciliation	From receipt to the correct match confirmed in accounts receivable
False positives	Proposed or accepted matches that validation finds incorrect
Rework	Corrected, reopened, re-entered, or manually reconciled cases
Queue age	Time open by cause, priority, and owner

A high auto-match rate does not offset a financial false positive. Publish results only with your own sample, period, and scope. Do not promise OCR accuracy or extrapolated return from a demo.

10. Know when not to build it

Do not start with an agent if volume is low and a shared inbox with a form solves the problem; if the ERP does not expose dependable IDs and states; if Finance has not agreed how to handle differences, partials, or duplicates; or if nobody can operate the queue.

Do not advance to writing when there is no supported API or mechanism, permissions cannot be limited, idempotency and a verifiable response are missing, or the team cannot stop and reconcile the process. In those cases, the first improvement may be to standardize intake, require minimum fields, repair master data, or provide a read-only view.

The agent makes sense when it connects frequent, bounded work to trustworthy sources, explicit rules, and available owners. Every receipt should end matched, under review, or rejected for a reason the team can verify.