Transaction processing

Transaction Processing

Purpose

Every financial transaction that hits the business — invoices received, expense reports, credit card charges, reimbursements — must be categorized, deduplicated, and flagged for anomalies before it reaches the general ledger. This skill ensures every dollar in and out is accounted for, properly categorized, and ready for posting, reducing bookkeeping errors and providing clean financial data for reporting.

When to Use

• "Process these transactions / receipts / invoices"
• "Categorize these expenses"
• "Enter these into the books"
• Upload of receipt images, CSV exports from bank/Stripe/QuickBooks, or raw transaction lists.
• "Reconcile and categorize this month's transactions"

Inputs Required

You must gather or receive:

1. Transaction source data — CSV export, bank feed, API dump, or manual list. Must include: date, amount, counterparty, description.
2. Chart of accounts — if not already known, load via ledger-management skill.
3. Previous period categorization — optional, for consistency checking.

Quick Reference

Concept	What It Does	Why It Matters
Auto-categorization	Maps transaction descriptions to COA categories using rules	Ensures every transaction has a home without manual effort
Deduplication	Scans for duplicate amounts/vendor/date combinations	Prevents double-counting, the most common bookkeeping error
Anomaly detection	Flags outlier amounts, missing fields, round numbers	Catches errors and potential fraud before ledger posting
Confidence scoring	HIGH / MEDIUM / LOW per categorization	Surfaces items that need human review
Multi-currency handling	Records original + USD-equivalent	Required for accurate P&L and cash reporting

Procedure

1. Parse the transaction file: detect format (CSV, JSON, PDF table). Extract: date, amount, counterparty, description, payment method.
2. Deduplicate: Check for duplicates against the existing transaction log. Flag any transaction that already appears.
3. Auto-categorize each transaction using these rules:
   • Software/subscriptions → Software & Subscriptions
   • Payroll/contractors → Payroll & Contractors
   • Rent/office → Facilities
   • Marketing/ads → Marketing
   • Travel/meals → Travel & Entertainment
   • Legal/professional services → Professional Services
   • Loan payments/interest → Debt Service
   • Revenue from customers → Revenue
   • Investments/grants → Other Income
   • Everything else → assign best-guess category and flag for review.
4. Flag anomalies:
   • Duplicate amounts to the same vendor in the same week.
   • Transactions over an outlier threshold (3x the median of the same category).
   • Round numbers that look like estimates rather than actuals.
   • Missing counterparty or description.
5. Prepare the output — a categorized transaction log.
6. (Optional) Post to ledger — hand off to ledger-management.

Output Format

A structured table (Markdown or CSV):

Date	Description	Counterparty	Amount	Category	Confidence	Flag
2026-04-01	Stripe payout	Stripe	$12,450.00	Revenue	HIGH	—
2026-04-02	AWS Invoice #8932	AWS	$3,421.00	Software & Subs	HIGH	—
2026-04-03	Lunch — Joe's Diner	Joe's Diner	$42.18	Travel & Entertain	MEDIUM	REVIEW: personal vs business?

Summary statistics at the top:

• Total transactions processed
• By category (pie or table)
• Flagged count / review-needed count
• Uncategorized count

Done Criteria

The skill is complete when:

1. All transactions in the source data are parsed, deduplicated, and categorized
2. Anomaly flags are applied and surfaced to the user
3. Summary statistics are provided (total, by category, flagged count)
4. Every transaction has a confidence score (HIGH, MEDIUM, or LOW)
5. The categorized log is ready for hand-off to ledger-management
6. No transaction is auto-posted to the ledger without human review when flags exist

Pitfalls

• Categorizing by payment method instead of nature: Categorizing everything from the corporate Amex as "Corporate Card" rather than splitting into actual expense categories (travel, software, meals)
• Forcing every transaction to HIGH confidence: Overriding the system's MEDIUM/LOW flags to avoid review items. Unreviewed medium-confidence items silently corrupt the general ledger
• Skipping deduplication on manual entries: Assuming manually-entered transactions are always unique. Manual entries are the most common source of duplicates — always scan
• Lumping bank fees into a single "Bank Charges" line: Payment processor fees, wire fees, FX markups, and account maintenance fees are fundamentally different costs and should be split if material
• Auto-posting without human review when flags exist: Processing a transaction batch with 3+ flagged items straight to the ledger without pausing for review. Flags exist for a reason — every flagged batch deserves a human sanity check before ledger posting

Verification

Can you trace any transaction from source data through categorization to the output table? Are all anomaly flags explained with a reason? Is the confidence score justified for each categorization? If a transaction is flagged MEDIUM or LOW, is there a clear path for the user to resolve it?

Example

Example 1: CSV Upload

User: "Here's our April bank export CSV — can you process and categorize all transactions?"

→ You parse the CSV, detect format (date/description/amount columns), deduplicate against prior months, auto-categorize each line item, flag 3 anomalies (one duplicate vendor payment, one $8,400 round-number transfer, one missing counterparty), and present a categorized table with summary stats and flags highlighted for review.

Example 2: Receipt Processing

User: "I have 12 receipts from our team's offsite — process these"

→ You extract dates, vendors, and amounts from the receipts, categorize all as Travel & Entertainment, apply the $500/receipt founder-scrutiny rule (none flagged since amounts are small), deduplicate against the period, and present a clean categorized batch ready for ledger posting.