Building an Automatic Reconciliation Engine: How We Match Receipts to Transactions

Traditional reconciliation systems rely on exact matches—same amount, same date, maybe some basic text matching. But real-world financial data is messy:

• Currency conversions create slight discrepancies in amounts
• Banking delays mean transaction dates rarely match receipt dates exactly
• Merchant names vary wildly between receipts and bank feeds (“Apple Inc.” vs “APPLE.COM/BILL” vs “APL*ITUNES.COM”)
• Processing fees and exchange rates introduce small amount variations

This messiness means traditional systems either miss obvious matches or flood you with false positives. We needed something better.

Our reconciliation engine doesn’t just look at one or two data points. It analyzes transactions and receipts across multiple dimensions simultaneously, using embeddings to understand the semantic meaning behind the data.

Before any matching happens, we run both transactions and inbox items through an extensive preprocessing pipeline:

Transaction Enrichment:

• Merchant name standardization using our provider network
• Legal entity resolution (connecting “AMZN” to “Amazon.com, Inc.”)
• Category prediction based on merchant patterns
• Currency normalization with real-time exchange rates

Document Processing:

• OCR extraction for receipts and invoices
• Tax rate and type detection (VAT, GST, Sales Tax)
• Date parsing with format normalization
• Amount extraction with currency detection

The key insight: clean, enriched data is the foundation of accurate matching. Garbage in, garbage out. So we invest heavily in making sure the data going into our matching algorithm is as clean and standardized as possible.

Here’s where it gets interesting. Instead of just comparing text strings, we use 768-dimensional vector embeddings to capture the semantic meaning of transactions and receipts.

const transactionText = prepareTransactionText({
  name: transaction.name,
  counterpartyName: transaction.counterpartyName,
  merchantName: transaction.merchantName,
  description: transaction.description
});

const embedding = await generateEmbeddings([transactionText]);

These embeddings allow our system to understand that “AMZN MKTP” and “Amazon Marketplace Purchase” refer to the same thing, even though the text strings are completely different. The system learns patterns like:

• “SQ *COFFEE SHOP” → “Square Coffee Shop Receipt”
• “PAYPAL *DIGITALOCEAN” → “DigitalOcean Invoice via PayPal”
• “APL*APPLE.COM” → “Apple App Store Purchase”

We use pgvector in PostgreSQL with HNSW indexing for lightning-fast similarity searches across millions of transactions.

Our matching algorithm evaluates four key dimensions, each with carefully tuned weights:

Embedding Score (45% weight): Semantic similarity between transaction and receipt text
Amount Score (35% weight): Financial accuracy with tolerance for fees and conversions
Currency Score (15% weight): Currency matching with cross-currency support
Date Score (5% weight): Temporal alignment accounting for banking delays

const confidenceScore = 
  embeddingScore * 0.45 +
  amountScore * 0.35 + 
  currencyScore * 0.15 +
  dateScore * 0.05;

But here’s the clever part—we don’t just calculate a simple weighted average. The algorithm has sophisticated logic for different matching scenarios:

Perfect Financial Matches: If currency and amount match exactly, we boost confidence significantly even with moderate semantic similarity.

Cross-Currency Excellence: For different currencies but matching base amounts (after conversion), we apply specialized tolerance calculations based on transaction size.

Semantic Strength: Strong semantic matches can overcome minor financial discrepancies, perfect for cases where fees or tips create small amount differences.

Not all matches are created equal. Our system categorizes matches into three tiers:

Auto-Matched (95%+ confidence): Automatically processed without human intervention
High Confidence (75-95%): Suggested with high priority
Suggested (60-75%): Flagged for manual review

The thresholds aren’t static. They adapt based on your team’s behavior through our learning calibration system.

This is where our system becomes adaptive. Every time you confirm, decline, or unmatch a suggestion, we feed that data back into a calibration algorithm that adjusts the matching thresholds for your team.

export async function getTeamCalibration(
  db: Database,
  teamId: string,
): PromiseTeamCalibrationData> {
  
  const performanceData = await db
    .select({
      matchType: transactionMatchSuggestions.matchType,
      status: transactionMatchSuggestions.status,
      confidenceScore: transactionMatchSuggestions.confidenceScore,
    })
    .from(transactionMatchSuggestions)
    .where();

  
  const calibratedThresholds = calculateAdaptiveThresholds(performanceData);
  
  return calibratedThresholds;
}

Conservative Teams: If you frequently decline suggestions, we raise the thresholds to be more selective.

Aggressive Teams: If you confirm most suggestions, we lower thresholds to catch more matches automatically.

Pattern Recognition: We learn your specific business patterns—maybe you frequently have small processing fees, or you often pay invoices 30 days after receipt.

The calibration system tracks multiple metrics:

• Auto-match accuracy rate
• Suggested match acceptance rate
• Average confidence scores for confirmed vs. declined matches
• Post-match unmatch rate (negative feedback)

Here’s how it all comes together when you upload a receipt:

1. Document Ingestion

• Receipt uploaded to inbox (email, drag-drop or Gmail auto sync)
• OCR processing extracts text, amounts, dates, tax info
• Document classified as invoice, expense receipt, etc.

2. Preprocessing & Enrichment

• Merchant name standardization
• Amount and currency normalization
• Date parsing with format detection
• Vector embedding generation

3. Candidate Identification

• Multi-tier database queries find potential matches:
  • Tier 1: Exact financial matches (same currency + amount)
  • Tier 2: Strong semantic matches with moderate financial alignment
  • Tier 3: Good semantic matches with loose financial tolerance

4. Scoring & Ranking

• Each candidate scored across all dimensions
• Team-specific calibration applied
• Best match identified with confidence level

5. Action Decision

• Auto-match: High confidence matches processed immediately
• Suggest: Medium confidence matches flagged for review
• Hold: Low confidence matches remain unmatched

6. Learning Loop

• User actions (confirm/decline/unmatch) fed back to calibration system
• Thresholds adjusted for future matches
• System gets smarter over time

Our matching engine is built for scale and reliability:

Database: PostgreSQL with pgvector extension for embedding storage and similarity search

Embeddings: Google’s Gemini embedding model (768 dimensions) with HNSW indexing

Background Processing: Trigger.dev handles embedding generation and batch processing

Caching: Intelligent caching of embeddings and calibration data

Monitoring: Comprehensive logging and performance tracking with automatic alerting

The system processes thousands of matches daily with sub-second response times, even as embedding databases grow into millions of vectors.

After months of refinement and thousands of hours of real-world usage, our matching engine achieves:

• 95%+ accuracy on auto-matched transactions
• Sub-second matching for most documents
• Cross-currency support with intelligent tolerance handling
• Learning adaptation that improves accuracy over time
• 99.9% uptime with robust error handling and fallbacks

Teams report saving 5-10 hours per week on reconciliation tasks, with receipts automatically matching to the right transactions without manual intervention.

We’re continuously improving the matching engine with several exciting developments in the pipeline:

Enhanced Document Understanding: Better extraction from complex invoices and multi-page documents

Predictive Matching: Suggesting matches before transactions even appear in your bank feed

Automatic Categorization: Category assignment based on matched receipt content

Multi-Document Matching: Handling cases where one transaction matches multiple receipts or vice versa

Advanced Learning: More sophisticated ML models that understand your specific business patterns

Automatic reconciliation is just the beginning. Clean, matched financial data unlocks powerful insights: cash flow predictions, spending pattern analysis, tax optimization, and automated reporting.

By solving the tedious problem of receipt matching, we’re freeing business owners to focus on what matters: growing their business.

The future of business finance is automation that works seamlessly in the background, and we’re excited to be building that future.