Currency mismatch detection in AI agent workflows

By KYN AI Advisory Team — AI implementation specialists, Singapore

An AI agent detects a currency mismatch by checking every amount against the currency and rate it expected, and by flagging any difference it cannot explain with a second signal. It does not round, convert or assume. The same design handles every deviation: a partial payment, a refund pair, a self-transfer, a malformed record. The agent follows its rules for the normal case, runs a separate exception check beside them, and sends ambiguity to a named person.

Why do agents miss deviations?

A playbook is a state machine. It defines expected inputs and a correct action for each. It cannot represent what it did not anticipate. An agent following one does not feel uncertainty at an unexpected case. It applies the nearest rule and moves on.

The result is quiet error. The wrong invoice matches the wrong payment. A malformed record enters the ERP. A guessed number lands on a customer document. Each is small. They compound, because the next step builds on the accepted error.

The fix is not a bigger playbook. No playbook lists every edge case. The fix is an exception layer: checks that run alongside the main workflow and ask one question, "does this match what I expected?"

What does a currency mismatch look like?

Three cases look alike and need different decisions.

1. A foreign-currency card charge that posts for more than the receipt. Conversion happens a day or more after checkout, at a different rate. The charge is correct. It is not an exact match.
2. An incoming payment short of an open invoice. The cause may be a partial payment, a sender-side bank fee or an exchange-rate shortfall. Each needs a different action.
3. A document in one currency and a request in another. A quote in SGD against a purchase request in USD is ambiguity, not a rate problem. The correct move is to ask.

An agent that auto-resolves all three with "close enough" will be wrong in some of them and will not tell you which.

How do you detect a mismatch without guessing?

Use a fixed order and a second signal.

1. Match in sequence. Amount first, then reference number, then counterparty name.
2. If the exact amount fails, widen on a second pass. Allow a tolerance for the currency pair and the settlement delay.
3. Accept the wider match only with a second independent signal. A matching reference number is one. A matching counterparty alone is not enough when amounts differ.
4. Otherwise, flag. Put the item in a review queue with the amounts, currencies, dates and the reason it did not match.

For KYN's own books, the rule is to claim the SGD the card actually charged, not the receipt's face value. The bank amount is the record, and the difference is explained by the card's conversion. The agent keeps both figures and the gap between them visible.

Treat a false positive as worse than a false negative. A wrongly marked-paid invoice erodes trust faster than an item that waits in a queue. Tune the system to under-resolve when in doubt.

Which other deviations need the same layer?

| Deviation | Why it matters | Handling | |---|---|---| | Charge and later refund | One economic event, not two items | Match as a net-zero pair | | Transfer between own accounts | Looks like a purchase | Filter before classification | | Missing quantity or currency on a request | A guess reaches an invoice | Ask a clarifying question | | Invoice numbering | Accountants and auditors expect an unbroken sequence | Follow the existing sequence, never invent one | | Master data wrong in an external system | The system rejects transactions outright | Correct reference data before the first transaction | | Two sources disagree | An average hides the gap | Report each source separately |

The common thread: resolve routine cases automatically so that human attention goes only to cases that need it.

When should an agent stop and ask?

Escalate on genuine ambiguity, not on every mismatch. A rule of thumb:

• If a rule plus a second signal explains it, resolve and log the reason.
• If the cause cannot be determined from the data, stop and ask.
• If it involves money out, a filing, a deletion or an outbound message, a named person decides.

Every flag should say what was expected, what was found and what the options are. A flag that reads "mismatch" is a flag nobody can act on.

Also cap retries. In any multi-pass process, such as draft, review and revise, limit the loops to a small number so a stubborn case reaches a person instead of cycling.

Why do sandbox tests pass and production fail?

Integrations to outside systems hide deviations. A sandbox accepts the cases the vendor expected and often accepts edge cases that the live system rejects. Two practices help.

• Correct master data first. Item masters, client masters and charts of accounts must be accurate and exactly formatted before any transaction is sent.
• Test against real data in an isolated copy. Run the build against a full copy of the production environment, kept apart from the live system until proven.

In KYN's manufacturer ledger, 3,309 reconciled rows were loaded with zero duplicates. That outcome came from matching rules that refuse to double-count, not from the volume of testing alone.

What does a worked example look like?

The figures are illustrative. An agent reconciles five bank lines against open invoices and receipts for a Singapore company that bills in SGD and pays suppliers in USD.

| Line | Expected | Found | Exact match | Second signal | Agent decision | |---|---|---|---|---|---| | 1 | Invoice INV-2041, SGD 4,200.00 | Credit SGD 4,200.00, ref INV-2041 | Yes | Reference | Match, log | | 2 | Invoice INV-2042, SGD 3,000.00 | Credit SGD 2,990.00, ref INV-2042 | No | Reference matches, gap SGD 10.00 | Match as paid short; flag the SGD 10.00 as a possible bank fee | | 3 | Supplier bill USD 500.00 | Debit SGD 676.40 on card | No | Merchant name matches, posted 2 days later | Match; store card amount as the record; log the rate implied | | 4 | Invoice INV-2043, SGD 1,800.00 | Credit SGD 900.00, no reference | No | None | Flag: partial payment or a different invoice; ask | | 5 | None | Debit SGD 5,000.00 and credit SGD 5,000.00 same day, own accounts | n/a | Both accounts are the company's | Filter as a transfer; no classification |

Lines 1 and 5 need no human. Line 2 resolves with a flag because the reference is a second signal and the gap is small. Line 3 resolves because the merchant and the timing explain the difference. Line 4 stops, because no second signal supports either explanation. One line in five reaches a person, and the person sees what the agent saw.

How do you set a tolerance that does not hide errors?

A tolerance is a rule, so write it down and version it.

• Per currency pair. A pair that moves little in two days needs a narrower band than one that moves a lot. Set the band from your own past settlement gaps, not from a guess.
• Per delay. Allow a longer band for a weekend or a public holiday than for a weekday.
• Absolute and relative caps. A band of a few dollars is acceptable on a large invoice and not on a small one. Use both.
• Never stack tolerances. If the amount is outside the band, a matching name does not rescue it. Only a second independent signal does.
• Review monthly. Compare the matches made inside the tolerance with what accounts later confirmed. Tighten the band if any were wrong.

What should a review queue show?

A reviewer should be able to decide from one row. Each flagged item carries:

1. The record, its source and its date.
2. What the agent expected and what it found, side by side.
3. The rule that did not hold.
4. The options the agent can offer, such as "match as partial payment", "match to INV-2044", "leave open".
5. A free-text field, and the name and time of the person who decides.

The decision feeds back. If reviewers choose the same option for the same pattern ten times, that pattern becomes a rule, and the agent stops asking. A person approves the new rule before it goes live.

How do you test an exception layer?

Build a fixed set of cases before the first live run, and keep it as a regression suite.

• Normal cases. Exact matches, so you know the layer does not over-flag.
• Known deviations. One case for each row in the deviation table above.
• Near misses. An amount off by one cent, a reference with a transposed digit, a name with a different spelling.
• Hostile or malformed input. An empty currency field, a negative quantity, text where a number should be.
• Repeat runs. The same file processed twice must produce the same result and no duplicates.

Run the suite after every rule change. A change that alters a past decision should show up as a failed case, not as a surprise in a month-end review.

What do you measure once it is live?

| Measure | What it tells you | |---|---| | Share of items auto-resolved | Whether the rules cover the common cases | | Share flagged | Whether the layer is too cautious | | Flags resolved the same way each time | Candidates for a new rule | | Reviewer overturns of auto-resolved items | Whether the tolerance is too wide | | Median age of an open flag | Whether the queue has an owner | | Duplicates found at month end | Whether idempotency holds |

Track overturns above all. An auto-resolved item that a person later reverses is the clearest sign that a rule is too loose.

What about retries and failures in the plumbing?

Not every deviation is in the data. A call to an outside system can time out, return a partial result or accept a request and then fail later.

• Make every write idempotent. A retry must not create a second ledger row. Use a key built from the source record so the same input yields one result.
• Retry with a limit. A small number of attempts with a pause between them. After the limit, stop and report.
• Report failures, including failed retries. A watchdog that retries silently hides a broken integration.
• Record the state. Each record has a status: received, matched, flagged, posted, failed. A record that sits in one status too long raises its own flag.
• Keep the raw input. Store the original message or file beside the result so a reviewer can see what the agent saw.

Who owns the exception layer?

Name an owner in finance or operations, not in IT. The owner reads the queue, approves new rules and signs off on tolerance changes. The engineers keep the system running. The rules belong to the people who know what a correct ledger looks like.

What is the smallest version you can ship first?

Start with one deviation class, not all of them. A reasonable first release has four parts.

1. A single comparison: expected amount and currency against found amount and currency.
2. A review queue with the fields listed above.
3. An action log with the actor on every decision.
4. A weekly report of flags raised, resolved and overturned.

Run it in shadow mode for two or three weeks. The agent proposes, a person decides, and you compare the two. When the agent's proposals match the person's decisions for a stated share of cases that you set in advance, let it resolve that class automatically and keep the log. Add the next class only after that.

How do you build the checklist into a new workflow?

Ask eight questions before shipping any agent workflow:

1. Where does it assume an exact match, and what happens when that fails?
2. Is a second independent signal available to widen tolerance safely?
3. Are look-alike events filtered before a decision point?
4. When it meets ambiguity, does it ask or guess?
5. Is reference data correct before transactions run?
6. Is it tested against a sandbox, a production copy or live, and which would expose the real edge cases?
7. Are retries capped?
8. Does a watchdog retry failures, and does it report when a retry also fails?

Every action should also be logged with the actor, so a deviation can be traced after the fact. See finance systems and operations systems.

What should the log record for an audit?

An auditor will ask four things: what was flagged, who looked, what they decided and when. Store one row per decision with the source record, the rule that fired, the reviewer's name, the outcome and the time. Keep the rule version as well. Without it you cannot explain why last quarter's decision differs from this quarter's.

Review the rule set each quarter. Retire rules that no longer fire, and record why each one was added.

Where KYN fits

KYN builds agents with rules-based logic for finance, operations, sales and marketing. Outbound messages, money, filings and deletions wait for a named person. Every action is logged with the actor, agents hold their own restricted accounts and the system runs in your cloud account. The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. For the wider pattern of approval, read what an AI sales agent is, and what it cannot do.

Frequently asked questions

How does an AI agent detect a currency mismatch?

It compares each amount with the currency and rate it expected, widens tolerance only when a second signal such as a reference number confirms the match, and flags anything else. It never converts or rounds to force a match.

Why not let the agent auto-resolve small differences?

Small differences have different causes: fees, partial payments, rate movement. Each needs a different action. Auto-resolving hides which one occurred and lets errors compound.

Does exception handling slow a workflow down?

Slightly, for the few cases that pause for a person. It saves more by avoiding the cost of unwinding a wrong match later. Routine cases still resolve automatically.

Checked 30 October 2026.

Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.

Start Building →