WhatsApp us

Blog9 min read18 Sept 2026

Expense tracking system in Singapore: custom or off-the-shelf?

Expense apps solve capture, not the judgment calls at month end: FX gaps, refund pairs, self-transfers. How a custom expense system handles them and who owns it.

Expense tracking system in Singapore: custom or off-the-shelf?

By KYN AI Advisory Team — AI implementation specialists, Singapore

An off-the-shelf expense app solves capture, which is the cheap part. Month end still drags because nobody has encoded the judgment calls: foreign exchange gaps, refund pairs, self-transfers and partial payments. A custom expense tracking system in Singapore encodes those calls as rules, flags what it cannot resolve and logs every decision. It is worth building when your reconciliation hours go on decisions, not data entry.

Why does reconciliation still take days after buying an expense app?

Because parsing a statement and matching by amount and date are table stakes. The time goes on what each transaction means. Your team still opens the statement, still looks at three lines that nearly match, and still asks a sales manager what a charge in Bangkok was for.

Before buying more software, measure where the finance hours go in a month. If most go on decisions rather than typing, another capture app will not move the number.

Why does automated matching break?

Matching by exact amount and date fails against real data in three places.

  • Foreign currency gaps. A card charge abroad often posts for a different amount than the receipt, because the card converts later at another rate. The fix is a second-pass match with a currency-aware tolerance, gated by a second signal such as the same vendor or booking reference.
  • Refund pairs. A charge and its refund are two statement lines. If the system treats them as two undecided items, settled transactions pile up in the review queue.
  • Self-transfers and bill payments. Transfers between a person's own accounts look like purchases. Remove them before they reach the "business or personal" queue.

A workable matching order is amount first, then reference number if the payer supplied one, then counterparty name as a fallback.

We hit these cases in our own books. KYN's reconciliation of one month's claims covered dozens of card charges, with foreign-currency charges reimbursed at the amount the card actually charged, not the receipt face value. That is the sort of rule a generic app lacks and a custom one encodes once.

What does an audit-ready expense trail record?

A trusted trail flags what it cannot resolve and learns a rule once instead of asking every month.

  • Treat false positives as worse than false negatives. A wrong match erodes trust and takes longer to find than an item left in a queue.
  • Flag, do not guess, when an amount does not match. A partial payment, a bank fee deducted at source and a conversion shortfall are different situations.
  • Learn a rule once. The same vendor's FX gap should resolve on every future statement.
  • Explain exceptions. Show what was not resolved and why.
  • Log every action with the actor. Who matched, who approved, when.
  • Respect existing numbering. Invoice and claim numbers follow whatever sequence your accountant expects.

Keep supporting documents linked to each line. Our guide to scanning receipts for GST claims covers the capture side, and the one on recording foreign currency expenses covers the conversion rules.

Should you build or buy?

| What you see | What it points to | |---|---| | Staff re-decide the same vendor exception every month | A rule never encoded | | Your accounting package rejects uploads | Reference data not in the format it expects | | The demo worked, your real data did not | Not tested on real history | | The review queue grows with settled items | Refund pairs and transfers not recognised | | Claims arrive as photos on WhatsApp | Capture channel the app does not support |

If two or more rows describe you, a custom layer is justified. If none do, buy an app. A workflow for approving expenses bolted on to the same weak foundation inherits the same exceptions.

What does a month-end match look like on real lines?

The statement lines below are illustrative. They show the three break points in one small batch.

| Line | Statement text | Amount | Receipt or pair | Rule applied | Result | |---|---|---|---|---|---| | 1 | Hotel, Bangkok | S$412.30 | Receipt THB 11,200 | Currency-aware tolerance plus same vendor | Matched; difference recorded as FX gap | | 2 | Online store | S$89.00 | Receipt S$89.00 | Exact amount and date | Matched | | 3 | Online store refund | -S$89.00 | Pairs with line 2 | Refund pair | Both lines closed, net nil | | 4 | Transfer to own savings | S$2,000.00 | None | Self-transfer list | Removed from the queue | | 5 | Taxi | S$23.40 | Receipt S$21.00 | Gap of S$2.40 with no rule | Flagged: tip, fee or wrong receipt |

Four of five lines resolve without a person. Line 5 goes to the review queue with the reason attached. The reviewer sees "gap of S$2.40, no rule for this vendor", picks an answer, and the system offers to remember it. If the answer is "tips on taxi receipts are normal up to S$3", the next statement resolves itself, and the S$3 cap is a written rule you can change.

How should foreign-currency claims be reimbursed?

Reimburse what the card charged, not the face value on the receipt. The staff member paid the card amount in Singapore dollars. A receipt in baht or US dollars does not show that. Record both: the original currency amount for the audit trail, and the statement amount for the payout.

Steps for each foreign-currency claim:

  1. Capture the receipt with its currency, amount and date.
  2. Find the statement line by vendor, date window and an amount range around the converted receipt.
  3. Store the statement amount as the claim amount.
  4. Store the receipt amount and currency as supporting data.
  5. Record the gap between the converted receipt and the statement. Large or repeated gaps from one vendor go to a person.

For the conversion rules in the books themselves, see recording foreign currency expenses in Singapore.

Who approves what?

Set approval limits as data, not as habit.

| Claim type | Auto-checked by system | Approver | |---|---|---| | Under a low limit, receipt matched, known vendor | Yes | Team lead, in a batch once a week | | Over the limit | Yes | Finance lead, one by one | | No receipt | No | Finance lead, with a written reason | | Foreign currency with a gap above the tolerance | Partly | Finance lead | | Claim by the approver themselves | Yes | A second named person |

The last row matters for audit. A person must never approve their own claim. The system should refuse it, not rely on a reminder.

What edge cases cause the most rework?

  • Split bills. One restaurant receipt covers three people's meals. Allow a claim to carry several shares and require each share to be tied to a named person.
  • Receipts in the wrong period. A claim submitted two months late falls in a closed period. Route it to the finance lead with the period noted, rather than posting it back-dated.
  • Duplicate submissions. The same receipt photographed twice, or claimed on both a card and a claim form. Match on vendor, date and amount, and block the second.
  • Card statement timing. A charge on the 30th may post on the 2nd. Match across a date window, not a single date.
  • Personal items on a business card. Allow a line to be marked personal and repaid, with the repayment matched when it arrives.
  • Mileage and per-diem claims. These have no receipt. Store the rule and the inputs, and require a named approver.

What should you do before the review call?

Collect three months of card statements, the claims you paid and the exceptions your finance lead remembers. Count how many lines needed a decision and how many were typing. That split tells you whether a custom layer is justified. It also becomes the baseline against which you measure the finished system.

How do you keep the rules from going stale?

Rules age. A vendor changes its billing currency, a card issuer changes its conversion timing, or a policy limit moves. Review the rule list once a quarter. Remove any rule that has not fired in six months, and list any rule that fired more than usual. A rule that suddenly fires often is either a new pattern worth keeping or a sign that something upstream changed.

What did KYN build for expenses?

Two things, described by industry.

  • A finance software startup: a receipts, claims and GST product, built to production in six weeks on Google Cloud.
  • KYN's own books: bills read from Gmail, receivables chased at 3, 14 and 30 days, and payroll on 2026 CPF rules, with claims held in a register for a person to approve before they post.

In both, nothing that moves money posts without a named person. Every action is logged with the actor.

Who owns the system?

Ownership passes to you once the build is paid for. The accounts, data and rules sit in a cloud account registered to your company, and the custom code and configuration become yours at that point. If you end the engagement, you remove KYN's access and the claims register, matching rules and approvals carry on. Each agent uses its own restricted account, and row-level security limits every user to their own claims. See the finance page and security.

How long does a build take and what does it cost?

The first 14 days are a review of your claims process, cards, accounting package and the people who touch them. A full build ships in under 90 days. The fee is a one-off build fee, then a monthly retainer of at least twelve months for changes, monitoring and fixes. It is quoted after the review. There is no price list.

Scope the exceptions at the review. That is when you decide which stay with a person.

Where KYN fits

KYN builds finance agents for SMEs inside their own cloud account, connected to the accounting package you already use. Matching, categorising and chasing run on rules; posting, payments and filings wait for a named person. See integrations.

Frequently asked questions

Why does expense reconciliation still take days after buying an app?

Apps capture receipts but do not encode judgment calls such as FX settlement gaps, refund pairs and self-transfers. Those need rules beyond amount-and-date matching, so manual review persists.

Should a Singapore SME build or buy expense software?

Buy when your needs are standard. Build a layer when staff re-decide the same exceptions each month, uploads are rejected by your accounting package, or the app does not fit your capture channel.

Who owns a custom expense system?

You do, after the final payment. The code, configuration and data stay in your company's cloud account, and withdrawing the developer's access does not stop the system.

Checked 30 October 2026.

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

Start Building →

Written 18 Sept 2026 · Checked 29 Oct 2026