How We Unlocked Base's Data Foundation for AI (Claude) Use Cases and Reporting

Base came to incro through a warm introduction from a partner already working with their team on strategy and analytics — someone who knew incro's track record with legacy ERPs specifically. The ERP is where Base's financial data actually lives. It's a capable system of record. It was never built to be joined, queried, or reasoned over by a dashboard, let alone an AI model.

Radosław Adamowicz, Base's CFO, and the finance team weren't short on data. They were short on a dataset — something structured and reconciled enough that a report, a model, or an AI agent could use it without someone manually patching exports together first. That gap gets more expensive once AI enters the picture. Pointing Claude at a spreadsheet gets you an answer. It doesn't get you an answer you can trust, unless something underneath guarantees the numbers are complete, current, and traceable back to source.

Base wanted both outcomes from one build: a database solid enough for day-to-day management reporting, and clean enough to eventually let Claude work directly on the numbers. That's a foundation problem before it's an AI problem — we don't do the second without the first.

• Financial data lived inside Comarch Optima, not structured for direct reporting, analytics, or AI use
• Five distinct databases needed to be extracted and modeled consistently: general ledger, opening balance, VAT register, cash & bank entries, and a AP/AR (payables/receivables) table mapping them all to each other
• Full history from the 2024 opening balance to present needed rebuilding — not just the current period
• Linking documents to the payments that settled them, so a single datapoint could be tracked from invoice to payment across tables that don't share obvious keys
• Every table had to be validated directly against Optima, with no manual exports to check against — we designed and verified the dump format ourselves, with no tolerance for silent drift
• The end goal wasn't a one-off export: it had to run on an ongoing basis, in both incremental (daily) and full-refresh modes
• Base's own engineering team needed to deploy and run it on their AWS infrastructure — not depend on incro indefinitely

Phase 1 — Discovery & Scoping

‍Every data foundation project starts by turning a broad ask into a precise spec. Base needed all the core financial data organized into a usable, ongoing feed, spanning GL, VAT register, and cash & bank at a minimum. We worked closely with Base's finance, BI, and DevOps teams to translate that into an exact, table-by-table design, and brought in their Optima infrastructure partner to align on how the feed should run technically. Because the downstream use cases were still taking shape, we built the architecture to stay flexible rather than lock into one specific use case too early.

Phase 2 — Building the Architecture

‍We built a PostgreSQL database fed directly from Comarch Optima, organized into tables that mirror how Base's finance team actually works — GL, VAT, cash & bank, and payables all structured for FP&A use, not a raw copy of everything Optima stores. Two feed modes were built in from day one: an incremental mode for new or changed records, and a full refresh for when something upstream gets corrected retroactively.

Phase 3 — Making the Tables Talk to Each Other

‍The AP/AR (payables/receivables) table is what ties everything else together — it's what lets a single invoice be tracked all the way to the payment that settled it, mapping GL, VAT, and cash & bank entries to one another. One detail mattered for correctness: a single VAT register line can correspond to multiple GL lines, since the GL breaks out every posting side behind a document — getting that right mattered more than making the join look simple.

Phase 4 — Iterating Against Real Usage

‍Base's team came back with detailed feedback across several rounds as they worked with the data in practice. We refined the dump iteratively until it was fully useful for FP&A, bringing our own domain knowledge on Polish GL and VAT conventions to bear wherever it added value.

Phase 5 — Handover, Not Lock-In

‍We delivered the complete solution with full technical documentation — every column mapped to its source Optima field, transformation logic, and value dictionaries — plus the codebase on a GitHub repository, ready to deploy on Base's own AWS infrastructure. Our role didn't end at handover: we've stayed on to support the team with questions, fixes, and further improvements as they put the database to work.

• A governed financial database covering GL, opening balance, VAT register, cash & bank entries, and payables/receivables, from the 2024 opening balance to present
• A PostgreSQL database fed directly from Optima, organized into tables built for FP&A use — not a raw dump of everything Optima stores
• Incremental and full-refresh feed modes, both exposed as endpoints Base can schedule and run itself
• A AP/AR table that maps GL, VAT, and cash & bank entries to each other, so a single invoice can be tracked through to the payment that settled it
• Full technical documentation and codebase delivered via GitHub, deployable on Base's own AWS infrastructure
• Every table validated directly against Optima, refined across multiple rounds of direct feedback from their finance and BI teams
• Ongoing support from incro since handover — not a one-off delivery

Base now has what most finance teams only discover they're missing once they try to do something serious with AI: a financial database, not just an ERP export. Every number in it traces back to Comarch Optima, and the whole thing runs on infrastructure Base owns outright.

The headline is a data pipeline. The real unlock is what it makes possible next: a finance and data team that can ask Claude questions directly against governed financial data, instead of exporting a spreadsheet and hoping the answer holds up. That's the difference between AI that looks convincing and AI you can put in front of a board.