Ask a CFO a question in plain English — "how much have we spent with this supplier across all entities this quarter?" — and you will watch finance teams spend three hours and four spreadsheets answering it. Not because the data does not exist. Because it lives in five ERPs, two e-invoicing portals, a treasury system, three bank feeds, a contract repository, and an inbox.

Every system stores its slice. None of them know about each other.

This is the fragmentation tax every mid-market and enterprise finance team pays. It is what limits AI in finance more than any model capability. It is also why we spent the last 18 months building Astral — a typed knowledge graph that is the substrate every Flowie agent reasons on top of.

This is the strategic argument for why a knowledge graph (not a warehouse, not another reporting tool) is the right shape for the finance and procurement layer. And what we have learned shipping it to production.

The fragmentation tax

A typical mid-market group running 4–8 entities has the following shape:

  • 3 to 6 ERPs (often a mix of SAP S/4HANA in some entities, Sage or Odoo in subsidiaries, NetSuite for the US business)
  • 2 to 5 banking partners with different file formats and APIs
  • 2 to 4 e-invoicing channels (Peppol for Northern Europe, ChorusPro for France, FatturaPA for Italy, native EDI for legacy partners)
  • 1 to 3 procurement tools (a sourcing platform, a contract repository, sometimes a punch-out catalog)
  • An inbox where suppliers send invoices addressed to "accounts payable" because they have no idea which entity is buying

Each system has its own definition of who is this supplier. Each system has its own internal ID. Each system has different fields populated, different completeness, different update frequency. Some are read-only. Some are eventual-consistency. Some are batch-synced overnight.

When you ask the CFO question above, the work is not analysis. The work is resolution — figuring out that "Acme Corp" in SAP, "ACME Corporation" in Sage, "acme-srl" in Odoo, and the legal entity at SIREN 552 081 317 are all the same supplier. Once you have done that, the actual answer takes 30 seconds.

Most of finance's time is resolution, not decision-making. AI cannot fix that with prompting. It needs a different shape of data.

Why warehouses are not the answer

The intuitive response to fragmentation is "build a data warehouse". Snowflake, BigQuery, and dbt make this easier than ever. But for finance and procurement, a warehouse is the wrong shape — even when it is well-built.

Three reasons:

1. Warehouses model rows, not relationships. A warehouse table tells you that invoice 8472 was issued by supplier 1138 to entity A on date X for amount Y. A knowledge graph tells you that invoice 8472 was issued by supplier 1138 who is registered as SIREN 552 081 317 whose UBO is person K who also controls supplier 9241 — which is the supplier you are about to onboard for entity B. The relationship is the answer. Warehouses make you join your way to it; graphs make it the primary citizen.

2. Warehouses are batch by nature. Finance and procurement are not. An invoice that arrives at 14:03 needs to be matched, validated, and routed — now, not in tomorrow's overnight build. The warehouse model assumes hours of latency between data event and data availability. Operational finance assumes seconds.

3. Warehouses ignore the lineage and provenance question. When an AI agent says "approve this invoice", the controller's first question is "based on what?". A knowledge graph carries the provenance of every claim — this came from SAP at 14:02, this matched against PO 4471 in Coupa created at 09:14, this was signed by the buyer in DocuSign on March 8. A warehouse stores the answer. A graph stores the reasoning.

This is not a theoretical preference. It is what makes the difference between an AI suggestion you can put in production and one you have to babysit.

What "knowledge graph" actually means

The term gets used loosely. Here is the rigorous definition we are working from:

A knowledge graph is a directed, typed graph where nodes represent entities (suppliers, invoices, contracts, employees, payments, products) and edges represent typed, semantically meaningful relationships between them (issued-by, matches, approved-by, paid-via, supersedes).

Three properties make it useful in finance:

  • Typed entities. A supplier is not a row of strings — it is a Supplier with required fields, optional fields, and validation rules. The same applies to invoices, POs, contracts, payments. Astral has 40+ entity types in finance and procurement domain.
  • Typed relationships. Issued-by is not the same as paid-by is not the same as approved-by. The semantics are encoded, not inferred.
  • Versioned state. Astral stores the full timeline of every entity. The supplier's bank account changed three times this year? Each version is queryable, with an audit trail of who changed it and when.

The rest of the world has been building knowledge graphs for two decades. Google's search index has been a knowledge graph since 2012 (it is what powers the right-hand info panel for any entity). LinkedIn's Economic Graph maps every company, role, and skill in the global workforce. Palantir's Foundry is a knowledge graph dressed as an analytics platform.

The piece that has been missing is one purpose-built for finance and procurement transactional data. That is what Astral is.

The three layers Astral runs on

Astral has three layers. Each one solves a problem the layer below it could not solve alone.

Knowledge layer. Connectors continuously sync entities from every system. ERPs feed in transactional truth. E-invoicing networks feed in regulatory truth. Banks feed in payment truth. The graph resolves these into a single canonical entity per real-world thing. "Acme Corp" becomes one node, with provenance back to every system that contributed to it.

Reasoning layer. Once entities are resolved and typed, language models become genuinely useful. An LLM grounded in a typed graph does not hallucinate — because it cannot make a claim that is not anchored to a graph entity with provenance. We use this for invoice matching, supplier risk scoring, anomaly detection, classification, and natural-language query.

Action layer. This is where most of the field is still catching up. Once you can reason on top of a graph, the next step is to act — issue a PO, approve an invoice, schedule a payment, send a message to a supplier. This is the Large Action Model territory (which we explored in our piece on AI agents). Astral exposes typed action grammars — every action is reversible, dry-run-able, and auditable.

What this unlocks (concrete examples)

Three examples from production:

Onboarding compression from weeks to hours. When you add a supplier to Flowie, Astral resolves them against 600M+ company records (D&B, INSEE, Pappers, Companies House, EDGAR, JCT, SEC), checks sanctions lists, fetches financial scores, and pre-fills 80% of the onboarding form. What was a four-week back-and-forth is a 20-minute review.

Cross-entity supplier intelligence. When you negotiate with a supplier in entity A, you see the full group exposure — what entity B paid them last year, what entity C's payment terms are, what dispute history exists across all entities, what concentration risk this supplier represents. The graph makes this one query. Without a graph, this is a quarterly project.

Real-time variance explanation. When the CFO sees a €1.4M overspend on the indirect category vs. budget, Astral can decompose it: "€890K is timing — 4 invoices that should have hit Q3 hit Q2 because suppliers accelerated. €410K is a single contract with Acme Group that was renegotiated up. €100K is FX on three USD invoices." In a warehouse, this is a half-day of analyst time. With a graph, it is a question.

What Astral is NOT (and what we are NOT claiming)

Three honesty notes — because the AI infrastructure space is full of overclaim:

Astral is not a world model. Yann LeCun's JEPA architecture, the broader research direction toward systems that simulate consequences of actions across a domain, is the right long-term frame for what AI agents in finance will eventually need. Astral is the substrate that direction will run on. We are advancing predictive capability, but we do not claim to be a finance world model today. The infrastructure is the moat. The capability layered on top is a roadmap.

Astral is not a replacement for your ERP. It does not store transactional truth. It indexes it. Your ERP is still the system of record for ledger postings, your bank is still the system of record for payments, your e-invoicing PA is still the system of record for legal invoice transmission. Astral is the layer that makes these systems finally talk to each other.

Astral is not "just" RAG over your finance data. Retrieval-augmented generation pulls text snippets and stuffs them in a prompt. That works for support docs. It does not work for finance, where the answer to "can we pay this invoice?" depends on graph traversal across 8 entities, 3 contracts, 2 PO statuses, and a sanctions check. RAG retrieves; a graph reasons.

Where we are going

The shape of the work for the next 12 months:

  • Predictive simulation. "If we approve this PO at this stage, what is the impact on cash forecast, period close, supplier ledger, and compliance posture across all 5 ERPs?" This is the world-model frontier. We are advancing layer by layer.
  • Multi-step rollout previews. Today, dry-run shows you what one action does. Tomorrow, dry-run shows you what a sequence of 8 actions does, with branching and confidence intervals.
  • Counterfactual analysis. "What would have happened if we had approved this invoice differently last quarter?" — replayable history with alternative branches.
  • Open the substrate. Astral is MCP-compatible. Build your own agents on top via the same protocol Anthropic standardized for AI tool use. The infrastructure shifts; the moat is the data.

The bottom line for finance leaders

Every AI investment you make in finance is bottlenecked by data shape, not model capability. If your data is fragmented across rows in five systems, the best LLM in the world cannot reason across it without a knowledge graph in the middle.

The question is not "should I build a knowledge graph?" — the question is "do I build one in-house, or do I run on Astral?". We have spent 18 months on the first version. The data is harder than the AI. We did the hard part so finance teams do not have to.

If you are evaluating where AI in finance lands in your stack, explore the Astral page or book a call. We will walk you through what is in production, what is on the roadmap, and what we have learned about the gap between the two.

The infrastructure shifts. The moat is the data.