Bank Statement Parsing & Financial Reporting

We built the core in Laravel with a pluggable parser architecture. An abstract bank parser provides shared date, amount and text normalisation. Each bank has its own parser class that detects its own layout: Meezan Bank, Bank Alfalah, NayaPay and SadaPay, plus a generic fallback. PDFs are read with smalot/pdfparser, and CSV, XLS and XLSX files with Laravel Excel. An account can store a preferred parser to override auto-detection. A regression test suite locks in the layout edge cases each parser has had to handle. On import, a de-duplication service checks a content hash and then looks for same-amount transactions within a day either side, matching them by normalised reference, event fields or similar descriptions. A transfer detector pairs opposite-signed transactions of similar amount across your own accounts within a set time window. A keyword-rule categoriser, configured in one file, tags each transaction and suggests its type. A ledger-rebuild service re-derives each account from its statement files and checks the derived opening balance against the recorded one. It then carries existing categories and notes over to the rebuilt transactions. Alongside the Laravel core, a second Laravel service reads Google Sheets through the Drive and Sheets APIs, finds the header row automatically and parses the expense and income blocks that sit side by side. A Google Apps Script job, run on a daily trigger, scans Gmail for alerts from an allow-list of providers. It parses each provider's alert format, skips messages it has already recorded and appends the transactions to a separate spreadsheet for each year.