What Semantic² reads, and how a finding is made

Anyone who handles cases with documents knows the moment: the number on the invoice does not match the number in the decision letter, and the question is who is right.

Semantic² is built to find that moment earlier. How that happens can be told in five steps.

#Step 1: Reading

It starts with a document. A decision letter as a PDF, an invoice as a scan, a contract as a photo from a phone. Semantic² reads all three.

For structured documents it takes fields directly; for scans it recognises text and layout and remembers where something stood.

That remembering matters more than it sounds. Every number that later appears in a finding points back to its location: invoice, page 2, item 4. Without that trail a finding would be nothing more than a claim.

#Step 2: Checking

Read is not yet checked. In the second step Semantic² compares what it read with three things: the rules, the contract and what was booked.

Rules are written in readable form, for example: "The hourly rate must not exceed the agreed rate." Or: "A service period must not be billed twice." Rules have versions, so it can later be traced which version applied at which time.

The contract supplies the values to check against: rate, period, scope. The booking supplies what was actually paid. Only the triad of rule, contract and booking makes a check that holds.

#Step 3: The finding

If the check finds a deviation, a finding is created. It always consists of four parts:

• the amount in euros at stake,
• the rule that was violated,
• the source, meaning the location in the document,
• the booking the finding refers to.

All four sit side by side on one card. Whoever reads it has to take nothing on trust. They can open the invoice, read the rule and call up the booking.

The example below shows such a card over the document it came from.

Invoice

Item 4 · deviating rate€184.50

FindingSample

€184.50

Rule

Rate × hours

Source

Invoice, line 4

Booking

Voucher 2026-0412

AcceptReject

#Step 4: The decision

Semantic² does not decide. The finding waits for a person who accepts or rejects it. Both are actions with a log entry: who, when, with which reason.

That is not a safety net to be removed later once the system is "good enough". It is the design.

The officer carries the responsibility for the case, so the officer makes the decision. Semantic² gives them the best basis for it that can be drawn from the documents.

This separation produces an honest metric as a side effect: the share of accepted findings. It shows how accurate the check is, measured against real decisions, not test data.

#Step 5: Writing back

An accepted decision goes back into the case system. There the case is corrected, reclaimed or confirmed, depending on the finding.

If the customer or citizen is to be informed, the reply can run through the Univerx Channel, with a shared view and, if needed, a signature.

That closes the loop: the document that triggered the case leads to a checked result in the same case.

#A note on scanned documents

Scans are where most document tools fail quietly: a smudged digit, a rotated page, a stamp over the amount. Semantic² marks the passage it read and shows it beside the finding, so an uncertain reading is visible rather than hidden.

If a value cannot be read with confidence, the finding says so. An officer then checks the original instead of trusting a guess. That is slower for one case and faster for the whole file, because nobody has to re-check what was read cleanly.

#Where Semantic² sits in daily work

Findings do not need a tool of their own. Through task routing they land in the workbins the case officers already work from, with a deadline and an owner.

If the person concerned calls, the contact-centre agent sees the state of the case and the open finding. Which checks suit benefit reviews particularly well is described in Reviewing claims and benefit documents.

#What this means for the rollout

Three things follow from these mechanics.

First: the pilot starts with one document type and one group of rules. Nothing more is needed to see whether reading and checking work in your documents.

Second: the rules come from you. Semantic² brings the mechanics, the department brings the knowledge of which deviation counts.

Third: numbers come only after the pilot. How many findings were accepted and what they were worth can only be read from your cases. Promises upfront would be guesses.

For how Semantic² relates to the EU AI Act, see the Trust Center. The path to a rollout is described in the guide Using document intelligence in cases.