By KYN AI Advisory Team — AI implementation specialists, Singapore
Reconcile an expense claim against what the card actually charged, in the card's currency, not against the face value on the receipt. A USD receipt paid on an SGD card is claimed at the SGD amount on the statement, including the card's foreign-exchange fee. We built our own claims process on that rule: every claim links to a statement line, a receipt and a named approver, and the system flags any claim that has no statement match. For the bookkeeping side, see how to record foreign currency expenses in Singapore.
What goes wrong with multi-currency claims?
Four things, repeatedly.
- The receipt shows one number, the statement another. A USD 20.00 software charge on an SGD card might post at a different SGD amount than a rate lookup suggests. The employee paid the statement amount. Reimbursing the receipt face value over- or under-pays them.
- Taxes are folded in or left out. Some receipts show the amount before GST, some after. The card charge is the total. Claims drift when people enter the receipt figure that looks right.
- Two cards, two currencies. A person holds an SGD card and a USD card. The same vendor can charge either. The claim form needs to know which card was used, not just the vendor.
- Duplicates. A receipt arrives by email and again as a photo. Both get claimed.
None of these is a hard problem alone. Together, at 30 or 40 claims a month, they eat an afternoon and leave a ledger nobody trusts.
What is the rule for the claim amount?
The claim equals the amount debited from the claimant's account, in the currency of that account.
- SGD card, SGD receipt: claim the SGD amount.
- SGD card, USD receipt: claim the SGD amount on the statement. Keep the USD amount as a reference field.
- USD card, USD receipt: claim the USD amount. The company books it at its own rate on the posting date.
This rule has a reason. The employee's out-of-pocket cost is what left their account. The company's cost is what it reimburses. Using the statement figure makes those two numbers the same, and the reimbursement is exact.
We recorded the card fee as part of the cost in our own books. If the card adds a foreign-exchange fee, the fee is part of what the person paid, so it belongs in the claim. A policy that excludes it is a valid choice, but it should be written down, because otherwise each reviewer decides alone.
How does the matching work?
Each claim starts from one of three sources: a receipt forwarded by email, a photo, or a statement line the employee selects. The system reads the receipt for vendor, date, currency and total, then looks for a statement line.
The statement match uses:
- Date window. Statement posting dates lag the receipt date by up to a few days. The window is configurable.
- Currency. A USD receipt should match an SGD line with a vendor descriptor, or a USD line on a USD card.
- Vendor descriptor. Statement text rarely matches the brand name. The system learns aliases after a person confirms them.
- Amount tolerance. For cross-currency matches, the SGD figure is compared with the receipt amount converted at a band of rates around the posting date. A wide band flags a match for review. It does not reject it.
When one statement line matches one claim, the system links them. When several claims could match the same line, a person chooses. When no line matches, the claim is held with a flag: no card charge found.
What controls sit around the claim?
Money moves only after a person decides, so the controls are about making that decision fast and safe.
| Check | What it catches | |---|---| | One statement line, one claim | Double claims for the same charge | | Receipt hash and vendor-date-amount key | The same receipt forwarded twice | | Policy limits by category | Meals, travel and software over the cap | | Approver is not the claimant | Self-approval | | Claim has a purpose note | Missing business reason | | Card owner equals claimant | Claiming someone else's card spend |
Approval and payment are separate steps. The approver sees the receipt, the statement line and the amount in both currencies. A named person approves. A named person releases the payment. Each action is logged with the actor and time.
What happens to GST?
GST can only be claimed where the receipt supports it, and the rules differ by supplier and by whether the business is registered. The system stores the GST amount shown on the receipt as its own field, not inferred from the total. A reviewer can then see which claims carry GST and which do not. For the receipt side, see how to scan receipts for GST claims in Singapore.
We do not compute GST for the user from a rate. We read what the receipt says and flag when the receipt has no GST line. The statutory treatment is a decision for the finance lead or the accountant.
What did we learn running this on our own books?
KYN uses this process for its own expenses. Two things changed the design.
First, a claimant can hold two parallel subscriptions on two cards, charged on different dates. The system needed the card as a first-class field. Matching by vendor alone mislinked them.
Second, reconciliation is a monthly rhythm. A batch of statement lines arrives, the system proposes matches, and a person clears the exceptions. Anything older than one cycle that is still unmatched gets a reminder to the claimant. That keeps old charges from piling up into a month-end problem.
Our bills are also read from email into the ledger, which feeds the same review queue. See our finance work for how the pieces connect.
What are the trade-offs?
- Statement dependency. Matching needs the statement. If a claim is filed before the statement arrives, it waits.
- Alias building. The first month has more manual matches until vendor aliases accumulate.
- Policy cost. Writing the rule for fees and GST takes a decision from the finance lead. Skipping it means each reviewer improvises.
Where KYN fits
KYN builds claims and reconciliation inside a system that runs in a cloud account in your name. Money waits for a named person, every action is logged with the actor, and the database uses row-level security so a claimant sees only their own claims. A finance software startup's receipts, claims and GST product was built to production in six weeks on Google Cloud.
The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. Pricing is a one-off build fee and a monthly retainer of at least twelve months, quoted after the review. See pricing.
Frequently asked questions
Should I claim the receipt amount or the card amount?
Claim the amount the card charged, in the card's currency. The receipt shows the merchant's figure. The statement shows what the employee paid, including any card fee.
Can claims be approved automatically?
Matching can be automatic. Approval and payment should wait for a named person, because a claim moves money and the approver confirms the business purpose.
How do you stop the same receipt being claimed twice?
Each statement line links to one claim only, and each receipt carries a hash and a vendor-date-amount key. A second submission is flagged before it reaches the approver.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
