Automate Bank Statement and Invoice Reconciliation with AI

Most businesses use QuickBooks Online or Xero for accounting. Their bank reconciliation features rely on simple rules that match transaction descriptions. This works for a one-to-one match, like a single rent payment. But these rules fail completely with batched payouts. A single deposit from Stripe for $15,320.50 might represent 15 different client invoices, minus 15 separate processing fees, plus a refund. A rule-based system cannot untangle that deposit, forcing a bookkeeper to split the transaction manually.

To handle invoices, companies add OCR tools like Dext or Hubdoc. These tools extract data from PDF invoices and create bills in QuickBooks. This creates a new problem: the invoice data and the bank data live in separate silos. The bookkeeper still has to manually match the Dext-created bill to the Plaid-synced transaction inside QuickBooks. This two-system approach does not automate reconciliation; it just automates data entry, leaving the hardest part unsolved.

Consider a 10-person agency processing 100 invoices a month. Their bookkeeper spends over 10 hours each month manually matching batch payouts. They match each invoice to the deposit, calculate the payment processing fees for each one, and create the corresponding journal entries to balance the books. Every month, this tedious process introduces small errors that compound by tax time.

The structural issue is that off-the-shelf accounting software is designed for generic, one-to-one transactions. The architecture separates invoice data ingestion from bank data matching. A true reconciliation engine needs to see both streams of data simultaneously to correctly allocate a single bank deposit across multiple invoices, fees, and refunds in a single, atomic operation.

The process starts with an audit of your existing chart of accounts and transaction sources. Syntora maps every bank account via Plaid and reviews 3 months of historical invoices to understand common vendors, line items, and payment patterns. This audit identifies the specific matching logic needed, such as handling batched payouts from Stripe or daily deposits from Square. You get a clear picture of the data before any code is written.

The technical approach uses a FastAPI service hosted on AWS Lambda. When Plaid reports a new transaction, it triggers the service. A separate endpoint uses the Claude API to extract data from incoming PDF or email invoices. The core logic, written in Python, matches invoice data against bank transactions held in a Supabase PostgreSQL database. This architecture correctly handles the N-to-1 matches that break other systems. A reconciliation that takes a bookkeeper 90 minutes would complete in under 5 seconds, and the system can process over 1,000 invoices per hour.

The delivered system provides a dashboard showing every transaction, the matched invoice(s), and the resulting journal entries. You receive the full Python source code in your GitHub repository and a runbook detailing system management. For a business processing 500 transactions a month, hosting on AWS Lambda and Supabase typically costs under $50/month. The system can sync journal entries to an existing ledger or operate as a standalone source of truth.