FDE Build Project · Accounting · Corporate Card

Overseas corporate card transactions,
auto-classified by a rule engine

We auto-classify Sinsta Presents' overseas (English) corporate card transactions with a deterministic rule engine, and surface only the ambiguous "hold" cases to staff — with grounding from card role, past history, and Google Drive approval-request matching. Card numbers are never stored on the server.

🏢 Sinsta Presents 👥 Corporate support · accounting staff 🧪 dev deployed · reproduction verified
87.4%English-transaction auto-classification rate (real data)
100%Auto-classification match rate (0 misclassifications)
0 digitsCard numbers stored on the server (last 4 only)
3 actionsUpload → confirm only the ambiguous → download
The Challenge

Three walls in classifying overseas transactions

English merchant-name transactions were especially hands-on for the settlement staff.

1

Judging each English transaction by hand

Because merchant names were in English, staff had to determine the purpose and account for each one — and the same merchant split by purpose across transactions (the same Amazon could be parts = materials cost vs. a business-trip purchase = travel cost).

2

Scattered grounding made it hard to reproduce

The record of what purpose, by whom, and under which approval a transaction was handled was scattered, making consistency, reproducibility, and audit trails hard to secure.

3

Risk of card number (PAN) exposure

Card detail files contained the full card number, raising exposure and security (PCI scope) concerns when uploading them to an automation tool.

The Solution

Upload the original Excel, get a labeled Excel

Staff upload the card statement as-is; clear-cut cases are organized automatically, and only the ambiguous ones are confirmed with grounding.

STEP 1

Upload

Upload the original card statement Excel (.xls/.xlsx) as-is to /labeling/.

STEP 2

Ingest · security

Truncates the card number to the last 4 digits and extracts only English transactions.

STEP 3

Rule-engine classify

Auto-classifies by deterministic rules, splitting off only ambiguous ones as "hold."

STEP 4

Hold recommendation

Recommends a purpose with approval, card-role, and history grounding.

STEP 5

Download

After confirmation, download the labeled Excel (card number masked).

Engine

Deterministic rule engine

Classifies with priority rules instead of an LLM — reproducible, auditable, and with no call cost.

  • Priority R0→R5→R2→R3→R1→R4→unmatched
  • R0 refund/blank · R5 hold merchants (eBay · Ali · DigiKey, etc.) → hold
  • R2 subscription/SaaS · R3 transport, lodging · R4 USD food & beverage → auto-classified
  • Records the applied rule and reason in the output (for audit)
Security · Core

A design that never stores card numbers

On upload it immediately truncates the card number to the last 4 digits and discards the full PAN column. The principle: "not storing it is the safest."

  • The 16-digit PAN is never persisted anywhere — DB, session, log, or output
  • Output Excel is masked as **** **** **** 0863
  • The original file is parsed in memory and deleted immediately
  • Google Drive access is read-only (drive.readonly)
Recommendation

Grounded recommendations for hold cases

For ambiguous transactions, it attaches a recommendation and grounding badges by priority (approval amount match > card role > approval brand > brand history > heuristic).

  • Only approval-amount-match cases are auto-confirmed (dropdown pre-filled)
  • Otherwise it only attaches a recommendation tag and grounding, and staff choose
  • Provides past history (date · owner · memo) to speed up the decision
Integration

Google Drive approval-request matching

Snapshots and parses approval-request PDFs in Drive, matches overseas commerce transactions by brand, amount, and date, and links back to the original approval request.

  • PDF parsing with Claude, with Vision fallback for scans
  • USD = local amount / KRW = billed amount, compared within a ±45-day window
  • Amount match = strong confidence (auto-confirm), brand only = medium
  • Shows the matching grounding as a link to the original approval request (Drive PDF)
"Classifying by hand, one by one, turned into three actions."

Clear-cut cases are organized automatically, and staff only confirm the ambiguous hold cases while looking at the grounding.

The Impact

2026-05 real-data reproduction verification

Reproduced with actual card statements, most English transactions were auto-processed without misclassification.

BEFORE
  • Judging each English transaction's purpose and account by hand
  • Re-judging the same merchant's different purpose every transaction
  • Scattered grounding made audit trails hard
  • Risk of exposing the full card number in the original file
AFTER
  • 87.4% of English transactions auto-classified (100% match rate)
  • Staff confirm only the remaining hold cases, with grounding
  • Applied rule and reason kept in the output, enabling audit trails
  • Only the last 4 digits kept — exposure risk minimized
Accuracy
87.4%

In real-data reproduction, 104 of 119 English transactions were auto-classified, and the match rate for auto-classified cases was 100% (0 misclassifications). Staff handled only the 15 hold cases.

Security

Minimizing regulatory scope at the source

The full card number is never left anywhere in the system — only the last 4 digits are kept. Output is masked and Drive is accessed read-only, minimizing exposure risk and PCI scope.

Tech Stack

Built on a proven stack

Classification by a deterministic rule engine, with only approval-request parsing by LLM. Reproducibility and cost, both handled.

Django Deterministic rule engine Claude (approval-request PDF · Vision parsing) standarda-core Google Drive API (read-only) xlrd · openpyxl Vanilla HTML/CSS/JS LangSmith tracing