AI-built financial dashboards over CRM + ERP + bank APIs

Founder-built P&L drill-down dashboard, generated by Claude Code, that unifies external sources: CRM, ERP, and bank-statement APIs. Output: interactive multi-level drill-down (per-franchisee / per-region / per-month / multi-year). Replaces outsourced fin-accounting services. Founder owns the spec; iterates in days, not the months of an outsourced provider.

A founder at a small franchise replaced an outsourced finance service with a Claude-built dashboard in ~2 weeks. Quoted: "we discovered data we always had but never saw." The dashboard surfaced a per-franchisee profitability variance that drove a re-pricing decision worth months of margin recovery. Pattern generalises across any CRM + ERP + bank combo.

1. Map the data: which fields live in CRM, ERP, bank? One spreadsheet per source.
2. Build connectors: API client per source, pulling into a small Postgres / SQLite warehouse on a daily cron.
3. Define the P&L tree as code: revenue → product line → region → unit. Each leaf has its source field documented.
4. Claude Code skill: build-dashboard <P&L-tree> → generates HTML + Plotly / Recharts dashboard.
5. Drill-down: every leaf is clickable; clicking pulls the underlying rows from the warehouse.
6. Weekly review meeting uses the dashboard live; bugs filed back as issues; founder ships fixes that week.
7. Document data quirks (data-residency regulation / other regulatory) inline in the connector code.

• Don't put live LLM in the dashboard hot path. Build dashboards as static / read-only over the warehouse; reserve LLM for the authoring + the natural-language Q&A layer. LLM in the rendering path produces a $200 / month bill and 5-second page loads.
• Long-term escape from vendor lock-in via local-LLM fallback is a stated plan from multiple operators but not implemented at production scale in this corpus. Treat it as roadmap, not present capability. Today's posture: design for portability (provider-agnostic prompts, standard model APIs, no proprietary tool-calling lock-in) so a future cut-over is possible, but do not architect today on the assumption that the local-LLM will match frontier quality.