Using document intelligence in cases

Many requests do not end in a conversation but in a file. Behind a payment there is a decision letter, behind the letter an application, behind the application an invoice.

Checking whether it all fits together means reading. And reading is work that repeats with every case.

Document intelligence takes over the reading and the first comparison. It does not decide. This guide explains when it is worth using, which checks make sense, what stays with people, and how to introduce Semantic² in a manageable pilot.

#When document intelligence pays off

Not every case with paperwork is a good candidate. The benefit is greatest when four conditions come together:

• Recurring: the same document type arrives regularly and in meaningful volume.
• Rule-based: what is correct can be put into rules, such as agreed rates, permitted periods or maximum amounts.
• Comparable: there is a reference to check against, for example a contract or a booking.
• Consequential: an overlooked deviation costs money, time or trust.

Cases where discretion tips the balance, where every case is unique, or where nobody can agree on rules are less suitable. There, a good knowledge base helps more than an automated check.

Typical fields of use fall into three industries. In the public sector it is decision letters, applications and evidence. In insurance it is claims and benefit documents. In healthcare it is invoices from service providers.

What all three have in common is that documents are checked against rules that can be written down, and that checking ties up a lot of reading time today. Document intelligence gives exactly that reading time back to case officers, for the decision itself.

#Which documents

Semantic² reads decision letters, contracts, invoices and the case data, as forms, scans or photos. Which document types count in your deployment is something you decide together in the pilot. Typical combinations look like this:

Almost every deployment starts with the contract or rule set. Without a reference, an invoice can be read but not checked.

#Which checks

Reading is not checking. Semantic² compares what it has read with three things: the rules, the contract and what has been booked. Only that combination produces a check that holds.

Rules are written in plain language, for example: "The hourly rate must not exceed the agreed rate." They carry versions, so you can later trace which version applied at which time. A check nobody can explain creates distrust instead of relief.

#What a finding looks like

When a check finds a deviation, a finding is created. It always has four parts: the amount in euros, the rule that was broken, the location in the document and the related booking. All four sit side by side.

Invoice

Item 4 · deviating rate€184.50

FindingSample

€184.50

Rule

Rate × hours

Source

Invoice, line 4

Booking

Voucher 2026-0412

AcceptReject

Reading a finding requires no faith. The case officer can open the invoice at the stated location, read the rule and call up the booking.

If one of the four parts is missing, the result is not a finding but a hint that needs closer review.

The article What Semantic² reads, and how a finding is made describes the mechanics in detail.

#What stays with people

Semantic² does not book, does not decide and does not send anything. Every finding waits for a person to accept or reject it. Both are actions with a log entry: who, when, and for what reason.

This separation is not a safety net to be removed later. It is the design. The case officer is responsible for the case, so the case officer makes the decision. That includes every question of discretion and of communication with the customer or citizen.

There are legal reasons too. Under Art. 22 GDPR, people have the right not to be subject to a decision with legal effect based solely on automated processing. Genuine human review is more than a click on "confirm".

#Keeping review from becoming rubber-stamping

When a system is right most of the time, people may start accepting findings without looking. A few simple measures counter this habituation:

• Reasons for acceptance and rejection: short, but mandatory. They force a real look and feed the rule upkeep.
• Spot checks: a share of accepted findings is reviewed by a second person.
• Visible uncertainty: values read with low confidence are marked and require a look at the original.
• Feedback to the business side: findings that are often rejected point to a rule that needs sharpening.

This way of working yields an honest metric: the share of accepted findings. It shows how accurate the checks are, measured against real decisions rather than test data.

#One case, worked through

An example makes the steps tangible. A benefits agency receives monthly statements from a service provider that delivers agreed services at agreed hourly rates. The statements arrive partly as PDFs, partly as scans.

Semantic² reads every statement, recognises line items, hours and rates, and remembers where each one sits.

It then compares them with the framework contract and the payments already booked. In one statement, the rate on a line item is above the agreed rate; in another, a period appears that was already billed the month before.

Both deviations appear as findings with amount, rule, source and booking.

The case officer opens the first finding, sees the line in the document with the contract clause beside it, and accepts it. With the second, she finds it is an agreed supplementary charge and rejects it, giving her reason.

The outcome goes back into the case system: one correction, one confirmation. The rejected supplementary charge is a signal to the business side to add an exception to the rule. That is how the checks become more accurate month by month.

#Scanned documents and reading quality

Scans are where document tools can fail silently: a smudged digit, a rotated page, a stamp over the amount. Semantic² marks the location it read and shows it beside the finding. An uncertain reading is therefore visible, not hidden.

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

Watch where documents come from during the pilot. Smartphone photos, faxes and copies of copies behave differently from digital originals. Knowing their share helps you interpret the results correctly.

#Writing rules: the business side's job

Semantic² brings the mechanics; the business side brings the knowledge of which deviation matters. Good rules are therefore the most important groundwork for any deployment. They emerge from a short, structured process.

1. Collect: which deviations do case officers find today, and which do they tend to miss?
2. Phrase: each rule in one sentence that a new colleague understands without explanation.
3. Source: name the source of each rule, such as a contract clause, a statute or an internal instruction.
4. Test: try the rule on closed cases before applying it to new ones.
5. Approve: record version, effective date and owner.

Start with a few rules that apply often. A small, well-kept rule group is worth more than an extensive catalogue that nobody maintains.

#Data protection and co-determination

Case documents almost always contain personal data, often of a sensitive kind. Check early whether a data protection impact assessment under Art. 35 GDPR is required. Univerx provides supporting documents and a data processing agreement on request.

Univerx stores data and media in EU regions. Decide how long documents, findings and logs are kept and who may access them. Public bodies handling social data face additional rules, described in the guide Digital citizen service.

Logs of acceptances and rejections also show who decides how quickly and how often. That can make them suitable for monitoring behaviour or performance.

In Germany, this engages works council co-determination under Section 87(1) no. 6 BetrVG, or the equivalent public-sector staff representation law. Involve the works council or staff council before the pilot.

#What to ask of any solution

Whether you are evaluating Semantic² or another tool, a few questions separate dependable document intelligence from a demo. Ask them before you decide.

• Source: does every finding show the exact location in the document, and can it be opened with one click?
• Rules: are the check rules readable, versioned and editable by your business side?
• Uncertainty: are values read with low confidence marked rather than estimated?
• Log: is every acceptance and rejection recorded with person, time and reason, and can the log be exported?
• Data location: where are documents and findings stored, and for how long?
• Control: can individual rules, or the whole check, be switched off at any time?

A solution without a clear answer to any of these questions shifts risk onto your case officers.

#Fitting into the case

Semantic² builds on Univerx AI and task routing. A case with documents is routed like any other contact; the only difference is that the first processing step is a check. Findings land in the same workspace as conversations and tasks.

After the decision, the outcome goes back into the case system, where it is corrected, followed up or confirmed. If the customer or citizen needs to be informed, the reply can run through the Univerx Channel, with a shared view and a signature where needed.

#Getting started: a pilot with one document type

A pilot starts with one document type and one rule group. That is all it takes to see whether reading and checking work on your documents. You bring real cases; Univerx brings the checks.

1. Selection: one document type with high volume and clear rules.
2. Rules: phrase a small rule group, source it and test it on closed cases.
3. Framework: settle roles, logging, retention and co-determination.
4. Operation: check new cases, accept or reject every finding, record reasons.
5. Evaluation: acceptance rate, reasons for rejection, lead time and value of accepted findings.

There are no figures until after the pilot. How many findings were accepted and what they were worth can only be read from your cases. Promises made in advance would be guesses.

#Roles in operation

Document intelligence changes work in several teams. Clear roles prevent rules from being orphaned and findings from piling up.

Set aside fixed time for the business side to maintain rules, especially in the first months. That is where it is decided whether checks become more accurate over time or go stale.

#Common misconceptions

#Checklist before the pilot

#Next steps

Document intelligence does not start with technology but with a question to the business side: which deviation would you like to see sooner? Once the answer is clear, the pilot is not far away.

More on Semantic² is on the add-on page.

The article Reviewing claims and benefit documents shows how it applies in insurance. The principles behind AI at Univerx are set out under Responsible AI. If you would like to choose a document type together, book a demo.