Loading the Elevenlabs Text to Speech AudioNative Player...The next generation of regulatory knowledge will not simply store documents. It will understand relationships between them, find the right information semantically and deliver it to humans, software and AI systems in a form they can actually use.
For more than two decades, one of the most difficult parts of fiscalization has been finding the right information.
A retailer entering a new country may need legislation, technical specifications, tax authority guidance, implementation documentation, examples, interpretations, news about regulatory changes and practical experience from previous projects. Much of this information exists, but it is usually distributed across different websites, documents and formats, often written in the local language and frequently changed over time.
This was one of the reasons we created the Fiscal Requirements Portal. The objective was to collect this knowledge, structure it by country and topic, continuously monitor regulatory developments and make fiscalization information easier to access.
That model remains extremely valuable, but artificial intelligence creates the opportunity for a significant next step.
The future portal should not only allow a person to find a document. It should allow a person, an application or an AI agent to find the exact piece of regulatory knowledge needed to answer a specific question.
This is where embeddings and vector databases become important.
A document is not yet knowledge an AI can reliably use
Traditional portals are primarily built around documents, categories and keyword search.
If I search for “invoice cancellation,” a conventional search engine looks for documents containing those words. This works reasonably well when the terminology used by the person searching is the same as the terminology used inside the source.
Compliance rarely works that neatly.
One country may speak about cancellation, another about voiding, another about correction documents, credit notes, storno transactions or transaction reversals. Two regulations may describe essentially the same business process using completely different vocabulary.
Even within one country, terminology can change between legislation, technical specifications and tax authority documentation.
Keyword search therefore has an inherent limitation: it searches primarily for words.
Compliance Intelligence has to search for meaning.
What is an embedding?
An embedding is a mathematical representation of meaning.
Instead of storing a sentence only as text, an embedding model converts that sentence into a vector consisting of many numbers. Texts that express similar concepts tend to be positioned relatively close to one another in this mathematical space.
Imagine the following two sentences:
“Cancellation of a previously issued fiscal receipt requires a reference to the original transaction.”
and:
“When voiding a sale, the identification of the initial fiscal document must be provided.”
A traditional search system may see very different words.
A good embedding model can recognize that both statements are discussing a very similar concept.
This becomes particularly powerful in an international compliance environment because regulations are full of different terminology describing related business processes.
Embeddings therefore allow us to move from lexical search toward semantic retrieval.
Why a vector database is different
Once regulatory content has been transformed into embeddings, these vectors need to be stored and searched efficiently.
That is the role of a vector database.
A vector database can receive a query such as:
“What happens if a retailer needs to cancel a fiscal transaction after the receipt has already been issued?”
The question itself is converted into an embedding. The database then searches for pieces of regulatory information that are mathematically closest to the meaning of that question.
The result might include paragraphs from legislation, technical specifications, our interpretation documents and implementation guidance, even where none of those texts uses exactly the words contained in the original question.
This changes the way a compliance portal can work.
Instead of:
Search → document → read 40 pages → find answer
we can move toward:
Question → relevant regulatory evidence → structured answer → source
That is a very different experience.
But a vector database is not a compliance engine
This distinction is extremely important.
Putting thousands of fiscal documents into a vector database does not suddenly create Compliance Intelligence.
Vector similarity tells us which information appears semantically relevant. It does not tell us whether that information is legally valid.
Consider a simple question:
“What information must appear on a fiscal receipt in country X?”
A vector search might find:
- the current legislation;
- an older version of the legislation;
- a technical specification;
- a news article announcing a future change;
- our implementation documentation;
- an FAQ;
- a document describing an exception applying only to a specific industry.
All of them may be semantically relevant.
Only some of them may be applicable to the specific transaction being analysed.
This is why compliance requires much more than embeddings.
Every piece of knowledge needs context.
For the Fiscal Requirements Portal, this means metadata such as country, jurisdiction, document type, authority, legal status, publication date, effective date, validity period, topic, affected taxpayer, transaction type, business process and technical system can become almost as important as the text itself.
A question about Serbia should not accidentally be answered using a Croatian rule simply because the two texts are semantically similar.
A regulation effective in 2024 should not override a requirement that became mandatory in 2026.
A proposal should never silently be treated as adopted law.
Semantic similarity finds candidates. Compliance logic determines whether those candidates are appropriate.
From document repository to compliance knowledge layer
This is where I see the next evolution of the Fiscal Requirements Portal.
Today, the portal already contains different forms of knowledge: regulatory news, official documents, technical specifications, presentations, interpretations, implementation documentation and accumulated experience.
The next step is to transform these artefacts into a common knowledge layer.
A simplified architecture could look like this:
Sources → processing → structured chunks → metadata → embeddings → vector database → retrieval → AI reasoning → cited answer
The first important step is processing.
A 150-page technical specification should not simply become one vector. It has to be divided into meaningful sections or chunks. Ideally, those chunks follow the structure of the regulation rather than arbitrary blocks of 500 words.
A section describing receipt numbering should remain conceptually separate from a section describing certificates.
Every chunk should retain its provenance.
We should always know:
Where did this statement come from?
That means preserving the document, section, page, jurisdiction, version and validity information behind every piece of knowledge.
This is fundamental for compliance.
The real power appears when an LLM is connected
The vector database becomes particularly interesting when combined with a large language model.
Instead of asking the LLM to answer a fiscalization question from what it learned during training, the system first retrieves the most relevant information from our controlled knowledge base.
The model receives that evidence and generates its answer based on it.
This is commonly described as Retrieval-Augmented Generation, or RAG.
For compliance, however, I believe we need to go significantly beyond simple RAG.
A normal RAG system may ask:
What text is similar to this question?
A Compliance Intelligence system should additionally ask:
Which jurisdiction applies?
Which version is currently valid?
Is this legislation, guidance, interpretation or our own implementation specification?
Does the rule apply to this taxpayer and transaction type?
Are there exceptions?
Has the regulation been superseded?
Can the answer be traced back to authoritative evidence?
This is where the difference between a general enterprise chatbot and a serious compliance system begins.
Hybrid search will probably be more important than pure vector search
Another important lesson is that semantic search should not replace traditional search completely.
Compliance contains many values where exact matching matters enormously.
Article numbers, XML fields, VAT codes, certificate names, error codes, API parameters and legal references should often be searched literally.
If somebody searches for:
“Article 146a AO”
we do not want the system to find something conceptually similar. We want Article 146a AO.
The strongest architecture is therefore likely to use hybrid retrieval, combining semantic vector search with conventional full-text and metadata-based filtering.
The system might first restrict information to Germany, then to currently valid documents, then search exact legal references and semantic similarity together, and finally use a reranking model to identify the best evidence.
That is far more powerful than simply asking an LLM a question.
Embeddings also connect information that humans may not connect immediately
There is another aspect that I find particularly interesting.
Once thousands of compliance requirements have been embedded, we can begin comparing regulations across countries semantically.
A requirement in Italy concerning transaction signatures may be similar to a requirement in Croatia even if the authorities use completely different terminology.
A refund procedure in Serbia may resemble a cancellation process elsewhere.
An obligation described as fiscalization in one jurisdiction may technically resemble an e-reporting obligation in another.
These relationships can help us identify regulatory patterns.
For global retailers and technology providers, that could become extremely valuable because it allows us to move from seeing every country as an isolated implementation toward recognizing reusable compliance patterns.
A retailer may still need 30 local implementations, but perhaps those 30 implementations represent only six or seven fundamental architectural models.
Discovering these similarities is one of the areas where embeddings could become much more than a better search technology.
The connection with a knowledge graph
I do not see vector databases and knowledge graphs as competing technologies.
They solve different problems.
A vector database is extremely good at answering:
“Which information is semantically related to this question?”
A knowledge graph is better at representing explicit relationships:
This requirement applies to this transaction.
This authority issued this regulation.
This regulation supersedes that regulation.
This receipt requires this field.
This taxpayer belongs to this category.
This rule becomes effective on this date.
Combining both could eventually create something significantly more powerful.
The vector database finds relevant knowledge.
The knowledge graph provides structure and relationships.
Rules determine applicability.
The LLM explains the result to a human or another system.
Together, these components begin to resemble what I would call Compliance Intelligence.
From answering questions to supporting software
The most interesting part may eventually have little to do with a chatbot.
Imagine a POS development team implementing a new country.
Instead of manually reading dozens of documents, their engineering tools could query the compliance knowledge layer:
Which transaction types must be supported?
Which fields are mandatory on the receipt?
Which numbering rules apply?
What happens offline?
How are refunds handled?
Which certificates are required?
The same knowledge could support requirements engineering, software design, test-case generation and compliance validation.
An AI coding agent could use regulatory knowledge while developing an interface.
A test system could generate country-specific scenarios.
A compliance tool could compare an existing POS specification against regulatory requirements and identify gaps.
At that point, the Fiscal Requirements Portal is no longer only a portal.
It becomes infrastructure.
Accuracy must remain more important than intelligence
There is one danger in this evolution.
AI systems are extraordinarily good at producing plausible answers.
Compliance requires something different: defensible answers.
For business-critical regulatory knowledge, the objective cannot simply be to reduce hallucinations. The architecture should make unsupported statements structurally difficult to produce.
Every answer should be connected to evidence.
The system should distinguish fact from interpretation.
It should know when sources disagree.
It should preserve uncertainty.
And sometimes the correct answer should simply be:
“The available regulatory sources do not provide enough information to determine this conclusively.”
That may not sound as impressive as an AI confidently producing an answer, but in compliance it is infinitely more valuable.
The next generation of the Fiscal Requirements Portal
The first generation of compliance portals solved an information problem: collecting regulatory knowledge and making it accessible.
The next generation has to solve a knowledge problem.
Embeddings and vector databases give us the ability to understand regulatory information semantically, find relevant knowledge across thousands of documents and connect questions with evidence that traditional search might never discover.
But they are only one layer.
For Compliance Intelligence, they need to be combined with high-quality source material, structured metadata, version control, legal status, effective dates, hybrid retrieval, knowledge graphs, rules, validation and clear provenance.
If we build those layers correctly, the Fiscal Requirements Portal can evolve from a place where professionals search for compliance information into a platform through which humans, applications and AI systems can consume trusted compliance knowledge.
And I believe that distinction will become increasingly important.
Because the future of compliance will not be about having more documents.
It will be about making regulatory knowledge findable, understandable, machine-readable and eventually executable.
