GraphRAG for Tax Investigation With Local LLMs

By Sabika Tasneem

11 min readNovember 11, 2026

Your RAG pipeline can find any invoice in a tax case file, but it can't tell you who approved the payment or how that person connects to the supplier.

In a simulated case, MCP Risker SA pays a supplier, JF Apex Technologies. Benjamin Dark approves every JF Apex invoice. Jason Dark is JF Apex's managing director. Each record checks out on its own, and the concern only appears when you connect them. That's where chunk-based retrieval-augmented generation (RAG) falls short.

In a recent Memgraph Community Call, Jacob Coles, a data scientist at Redfield, showed how GraphRAG makes those connections. Because the case files are confidential, the whole pipeline runs on local LLMs.

Watch the recording for the full demo, or read on for a quick walkthrough below of the investigation.

Why Basic RAG Falls Short

Basic RAG works when the answer lives in one place. It splits documents into chunks, embeds them and retrieves the chunks closest in meaning to your question. Ask "What does the JF Apex invoice say?" and it can find the invoice that names the supplier.

Now ask the question the investigator actually has: "Which payments, approvals, and supplier records support the concerns about JF Apex?" That answer doesn't sit in any chunk. You have to aggregate across the ledger, follow who approved what and check how those people connect to the supplier.

As Jacob explained, once a question means aggregating over a set of transactions or every contract from the last ten years, similarity search stops being enough. Miss one record and the totals no longer validate, and you're back to checking manually.

SQL handles clean ledgers well. It struggles when the facts you need are buried in memos and emails next to those ledgers. A knowledge graph covers both, because it maps who and what is connected to whom, whatever document each fact came from. It's the same reason fraud is better treated as a relationship problem than a record-by-record one.

Building the Knowledge Graph

Redfield's setup combines a private LLM, a knowledge graph in Memgraph and an agent that queries the graph. The LLM does double duty. It extracts structure from documents at ingestion, and it generates queries during the investigation. Redfield tested gpt-oss and Gemma, and both worked reasonably well for each job.

The simulated case file holds 50 documents, including payments, invoices, supplier files and memos. They reach the graph by two routes:

Structured records, such as ledger rows, are converted by rules.
Narrative documents, such as memos and emails, go through the local LLM. It extracts entities, amounts and relationships into structured JSON that follows a predefined schema.

Both streams are then checked and merged. Entity resolution makes sure the same supplier or person, mentioned in different documents, ends up as one node. Jacob called it hard and specific to each use case. It can combine an LLM with grouping or clustering. The resolved graph is stored in Memgraph.

Diagram of Redfield's GraphRAG pipeline. Structured records pass through rules and narrative documents pass through a local LLM. Both merge at entity resolution into a Memgraph knowledge graph, which an investigator queries through an agent and the Memgraph MCP server, all on local infrastructure.

Building the graph is the hard part, and Redfield's own tooling does most of that work. If you're building something similar, Memgraph's guide to knowledge graph creation walks through the same pipeline steps, from entity extraction to disambiguation.

To answer questions, the agent connects to Memgraph through the Memgraph MCP server and runs Cypher queries. In the demo, that agent is Memgraph Lore, a graph intelligence workspace.

GraphRAG Demo: Step-by-Step Tax Investigation

With the case in the graph, the investigation becomes a conversation. Each question below is asked in plain language. The agent reads the graph's schema, writes Cypher, runs it, and presents the result.

The questions center on two companies, two people and the open lead between them.

Case graph linking MCP Risker SA, JF Apex, Benjamin Dark and Jason Dark, with a shared-surname lead.

Jacob recommends starting broad and narrowing down, which is the order here. The Lore screenshots below come from a pre-release build.

Get a Case Overview

Give me an overview of the case, the main companies, people, and any concerns raised.

The agent returned a case overview with the company and its sector, the principal people, and the concerns and findings. It grouped the concerns into four buckets and described a network linking suppliers, internal departments and regulatory bodies.

Memgraph Lore chat showing a generated overview of the MCP Risker SA case, with the company, principal people, and concerns grouped into four buckets.

None of this was prebuilt. The agent worked it out from the schema, which tells it what kinds of entities exist and how they connect.

Trace the Payments

How much was paid into JF Apex and who approved those payments?

The agent pulled the payments to JF Apex from the extracted ledger records, named Benjamin Dark as the approver and added a few key takeaways. The answer lists the invoice references behind the total, so you can check it against the ledger.

Memgraph Lore answer listing payments to JF Apex Technologies and naming Benjamin Dark as the approver.

Map the Connections

Show the recorded connections between JF Apex Technologies, its payment approver Benjamin Dark, and its managing director Jason Dark.

The result is a small graph with the organization and two people. An INVOLVES relationship connects them to JF Apex, and a RELATED_TO relationship links Benjamin Dark, who approves the payments, to Jason Dark, the supplier's managing director. That one edge turns two routine records into a possible conflict of interest worth reviewing.

Graph visualization in Memgraph Lore showing JF Apex Technologies connected to Benjamin Dark and Jason Dark, with a relatedTo relationship between the two men.

Verify Against the Ledger

Build a prepared JF Apex review from the supplied records and show a relevant map of the ledger records in the extracted graph.

Now you check the claims against the books. The agent assembled a review listing each invoice with its approver and amount, plus a map of the ledger records in the graph.

Memgraph Lore review of JF Apex invoices with their approvers and amounts, alongside a graph map of the related ledger records.

Jacob frames this step as comparing what should happen with what did happen. Where the records line up, the item is settled and you move on. Where there's a gap, you have a lead, although a gap can also mean the information simply wasn't found. Jacob suggested an investigator might skip as much as 90% of the manual checking they’d otherwise do

Search for Circular Payments

Show me circular payments that leave Jason Dark through 2 to 4 companies and return to him.

This is a different kind of question. Instead of checking known records, it hunts for money that leaves a person, passes through two to four companies and comes back. That's a variable-length path query, the kind of multi-hop pattern matching that graphs handle natively and SQL makes hard to express.

The agent found no circular payments, which is the expected result for this case. A clear "nothing found" still saves you ruling that pattern out by hand.

Surface What's Unverified

What do the records establish about Benjamin Dark's payment approvals and Jason Dark's role at JF Apex? What remains unverified about their relationship?

The last question runs as a deeper investigation, and you can watch every step. The agent fetched and read the schema, ran queries and retried the ones that failed. Jacob put the failures down to the small model, the trade-off for running privately.

The answer came back in two parts. The first lists what the graph proves, which is Benjamin Dark's payment approval activity and Jason Dark's job title. The second lists what the graph doesn't verify about their relationship, and that list tells the investigator where to dig next.

Memgraph Lore table separating what the graph proves about Benjamin Dark and Jason Dark from what remains unverified about their relationship.

Why Small Local Models Work

Small local models are less capable than hosted frontier models, and the agentic tooling around them is less mature. Jacob's argument is that the graph makes up much of the difference, because it narrows what the model has to do.

It does that at every step:

At ingestion, the model fills in a schema you defined instead of inventing structure.
At query time, it writes Cypher against labels it knows exist.
When a query fails, the agent retries.
The data it lands on is already structured, so it isn’t reasoning over loose text.

This works best with a well-defined schema, a point Jacob came back to in the Q&A below.

The trade-off runs both ways. Invest in ingestion, and querying becomes almost obvious. Even a general-purpose agent may work well. Skimp on ingestion, and you can still be clever at query time, for example with community detection, but you've only moved the effort to the other end.

The payoff is sovereignty. The model, the embeddings and the database can all run on your own infrastructure, and in Redfield's setup nothing is sent to a cloud provider.

Wrapping Up

GraphRAG earns its place when:

Your evidence is spread across formats.
Your questions aggregate records or follow connections.
Your data can’t leave your infrastructure, so a small local model needs the structure a graph gives it.

Tax investigation is one fit. Jacob pointed to any case where documents have to be reconciled with structured records, such as catching an invoice that was paid twice. If your questions are single-document lookups, basic RAG is enough. If everything already sits in a clean ledger, SQL is.

To see the full workflow, including the agent's retries, watch the Community Call recording. Memgraph Lore launches on December 8, and you can join the launch event to see it live. To connect your own agent to a graph today, start with the Memgraph MCP server.

Q&A

Here’s a compiled list of the questions and answers from the community call Q&A session.

Note that these are paraphrased slightly for brevity. For complete details, watch the full community call recording.

Which Other Use Cases Suit GraphRAG Better Than Basic RAG?
- Any case where different data formats need to be unified. Contracts or other text records that have to line up with structured data are a typical fit. So is a supplier invoice that was accidentally paid twice, which is easy to miss unless you can trace the payment back to the original invoice.
  
  Whether it works depends more on ingestion than on the domain. Jacob's advice was to:
  - Design a schema that aligns your different sources.
  - Build an extraction pipeline per source, such as contracts, invoices and emails, into one graph.
  - Add the discovery queries and tools you need, for example by forking the Memgraph MCP server. The standard tools may already work well.
Why Use a Structured Schema Instead of a Fully Flexible Graph?
- A query can only find what the graph has labeled. Say you want circular payments between two people who have emailed each other. The graph has to know which nodes are people, which are companies and which are invoices, or the query has nothing to grip. The same goes for an agent like Lore. Ask it about people who did something specific, and it can only answer if the graph knows which nodes are people.
  
  A graph doesn't need a schema, but Jacob sees one as a deliberate set of rules that keeps the data useful later. In his words, "something too flexible is almost not useful anymore."
  
  A loose schema hurts retrieval across the whole pipeline, and that many teams she talks to choose a fixed schema for use cases like this one. Memgraph's guide to modeling a knowledge graph covers how to design those labels.
How Does Retrieval Differ Between GraphRAG and RAG?
- It depends on how well you index. If each document type is processed to extract the right entities and the schema is fairly constrained, querying becomes straightforward and it's almost obvious how to traverse the graph. When that isn't possible, you can do more at query time, for example with community detection, which clusters the graph so the agent can search the relevant parts. However, you've then moved the effort from ingestion to querying, and the right balance depends on the use case.