Why every value in a loan file should link to the page it came from

A loan file today is rarely read end to end by one person. Documents arrive from the borrower, a DSA or a branch. Someone or something pulls out the net salary, the employer name, the date of birth and the average monthly balance. Those values go into a credit memo or a scorecard. By the time the file reaches a sanctioning officer, the numbers have travelled a long way from the paper they came from.

That distance is where most quiet errors live.

The problem with a confidence score

Many extraction tools return each value with a confidence score. A net salary of a given amount, "high confidence". A PAN, "medium confidence". This looks helpful, but it answers the wrong question.

A credit officer does not need to know how sure a model was. They need to know whether the value is right, and the fastest way to know that is to see where it came from. A score tells you nothing about which payslip, which month or which line was read. It cannot tell you whether the model read the gross figure instead of the net, or took the salary from a different employee's payslip that was scanned into the same PDF.

Confidence is also hard to act on. If a value comes back at "medium", what should the reviewer do? Open the original, find the page and read it themselves. In other words, the score has not saved any work; it has only told the reviewer where to start searching.

What goes wrong when values cannot be traced

When extracted values are not tied to a page, a few failures repeat across lenders:

• Silent substitution. A model fills a blank field with a plausible value from elsewhere in the file, or from nowhere at all. The output looks complete, and nobody knows a field was missing.
• Wrong document, right format. A salary is read from an older payslip, or from Form 16 instead of the latest month. The number is real; it is just not the one policy asks for.
• Untestable disputes. When an auditor, a collections team or the borrower later questions a figure, nobody can show where it came from. The answer becomes "the system said so".
• Corrections that do not stick. A reviewer fixes a value in a spreadsheet, but the fix is not tied to the document. The same mistake recurs on the next file.

None of these show up as errors on a dashboard. They show up months later, in a delinquent account, an audit observation or a complaint.

What a credit officer actually needs to see

The useful unit of evidence is simple: the value, the document it came from, the page, and the region on that page, shown side by side. One click from "net salary" should open the payslip at the line that says net salary.

With that in place, review changes character. The officer is no longer re-reading the whole file. They are checking a short list of values against the exact spots they were taken from. A correct value takes a glance to confirm. An incorrect one is obvious, because the page is right there.

Traceability also makes cross-document checks meaningful. If the name on the PAN, the name on the payslip and the account holder on the bank statement differ, the officer should see all three, each linked to its page, and decide whether the difference is a spelling variation or a different person.

RBI's FREE-AI committee report, released in August 2025, makes a related point about AI in credit: assessments should not work as a black box and should be done in a manner that is auditable. Linking each value to its source is one of the most practical ways to make extraction auditable, because the evidence travels with the number.

Flag, do not fill

The second rule matters as much as the first. When a value cannot be found or confirmed, the system should say so plainly and leave the field empty, rather than fill it with a best guess.

A blank field with a reason, such as "net salary not found on page 2", "date of birth unreadable" or "names do not match", is useful. It tells the reviewer exactly what to chase. A filled field that is wrong is worse than useless, because it carries the same weight as a correct one.

This applies with particular force to language models. They are good at producing fluent, complete-looking output, which is exactly the property you do not want when a document is incomplete. A sound extraction process treats "I could not confirm this" as a valid and expected answer.

How to put this into practice

If you are assessing an extraction process, in-house or bought, ask a few direct questions:

1. Can a reviewer open the exact page and region behind every value in one step?
2. When a value is missing or unreadable, does the output say so, or does it fill something in?
3. Are cross-document mismatches shown with each source linked, rather than resolved silently?
4. When a reviewer corrects a value, is the correction recorded against the document, with who made it and when?
5. Is that record kept somewhere it cannot be quietly edited later?

These are the principles we built Parse, the document part of Inferova, around: every value links to the page it came from, and what cannot be confirmed is flagged for a person rather than filled in. Reviewer corrections are kept with the document, so the record of what was checked stays complete.

The aim is not to remove the credit officer from the loop. It is to make their time count, so they spend it on judgement rather than on hunting through PDFs.

If you would like to see how this works on your own loan files, you can request beta access at inferova.com/demo.

Sources