Multi-Entity Document Mapping: Assigning Every File to the Right Borrower

You map on identifiers, not names. Build an entity register for the group, pull the PAN, GSTIN, CIN, EIN, TRN, trade licence and account numbers off each file, score every document against the register on those, resolve the period separately, and route the ambiguous few to a human. Names are the weakest signal in the file.

Nobody writes about this step, and it is the step where group credit files go wrong. Extraction accuracy is irrelevant if a correctly extracted figure lands on the wrong company — which is why YuSight's Document Intelligence runs entity mapping before extraction, ahead of the 95.2% extraction accuracy it measures against a manual benchmark.

Key facts

• Under the Basel large exposures standard, a bank's exposure to a group of connected counterparties is capped at 25% of Tier 1 capital — 15% between global systemically important banks — and every exposure at or above 10% of Tier 1 must be reported, along with the 20 largest regardless of size (BIS FSI). Getting entity boundaries wrong is a regulatory reporting error, not just an analytical one.
• An Indian GSTIN is 15 characters, of which characters 3 to 12 are the entity's PAN (ClearTax). A GST return therefore identifies the entity as precisely as a tax return does, and pins the state as well.
• The fourth character of a PAN encodes the holder's status — P for individual, C for company, F for firm or LLP, H for HUF, T for trust, A for association of persons (Income Tax Department). One character tells you whether a document belongs to the borrower or to its promoter.
• An Indian CIN is 21 characters carrying listing status, industry code, state, year of incorporation, company class and ROC registration number (ClearTax). A UAE TRN is exactly 15 digits, issued by the Federal Tax Authority and verifiable free on the FTA portal (FTA).
• Globally, LEI Level 2 data — "who owns whom" — records each entity's direct accounting consolidating parent and ultimate accounting consolidating parent (GLEIF). Where the group has LEIs, that is a machine-readable group structure you do not have to infer.

Why is misassignment dangerous, not just annoying?

Because a misassigned document is not obviously wrong. It is a real figure, correctly extracted, cited to a real page, sitting under the wrong name — the failure mode most likely to survive review.

Three specific ways it hurts.

A promoter's personal return spread into the operating company. The promoter files an ITR-3 declaring ₹1.42 crore of income, most of which is salary and dividend paid by the operating company. Treat it as additional company profit and the DSCR moves:

• Correct: (PAT 3.94 + Depreciation 3.41 + Interest on term debt 1.62) ÷ (Interest 1.62 + Scheduled repayment 4.10) = 8.97 ÷ 5.72 = 1.57x
• With promoter income added: (3.94 + 1.42 + 3.41 + 1.62) ÷ 5.72 = 10.39 ÷ 5.72 = 1.82x

Against a covenant floor of 1.75x, that is a fail turned into a pass. The rupees are not new — they left the company as salary and dividend. They have been counted twice, once inside PAT and once again on top.

A subsidiary's bank statement counted at parent level. The holding company's own current account averages ₹0.42 crore. The operating subsidiary's account averages ₹2.18 crore. Map the subsidiary's statement to the parent and parent liquidity reads ₹2.60 crore — 6.2x the truth. If the facility sits at holding-company level with a minimum-balance undertaking, the covenant test is now measuring a bank account the borrower does not control.

Consolidated and standalone accounts added together. The group files consolidated FY25 revenue of ₹186.40 crore. The subsidiary's standalone accounts show ₹41.60 crore, already inside that consolidation. Sum them and group revenue reads ₹228.00 crore — an overstatement of 22.3% — with every downstream margin, turnover and gearing ratio wrong in the same direction.

None of these produce a broken spread. They produce a coherent one. That is the problem, and it is the same structural problem we describe in how to stop an AI credit memo tool from hallucinating numbers: wrong-entity attribution is a figure that verifies clean when you click the citation, because the citation is genuine.

What signals actually resolve entity identity?

Ranked by how much weight they should carry.

The practical rule: a document with a machine-readable identifier that validates against the register is assigned automatically. A document with no identifier is a candidate for human review, no matter how confident the name match looks.

Why does fuzzy name matching alone fail?

Because it produces false positives on different entities and false negatives on the same one — simultaneously.

Legal-suffix drift. "Private Limited", "Pvt Ltd", "Pvt. Ltd.", "P Ltd", "(P) Ltd" and "PVT LTD" are the same suffix. In the US: "LLC", "L.L.C.", "Limited Liability Company", plus DBA names that never match the legal name at all.

Bank account-name truncation. Core banking systems truncate the account title. "Vaikundam Precision Components Private Limited" appears on the statement header as VAIKUNDAM PRECISION COMPONE. Character-level similarity to the legal name is low. It is the same entity.

Honorifics and prefixes. "Sri", "Shri", "M/s", "The" — present on the incorporation certificate, absent from the sanction letter.

Transliteration. Vaikundam, Vaikuntam, Vaikuntham. Al Marwan, Al-Marwan, AlMarwan. Each is a legitimate romanisation appearing in different registries.

Common promoter names. A file with three individuals named R. Kumar, one of whom is the borrower's director, one a guarantor and one an unrelated signatory on a stock statement.

Shared addresses. All four entities in a group registered at the same Chennai address, with the same auditor, the same company secretary and the same phone number on every letterhead.

And the killer, which is structural rather than cosmetic: token-overlap similarity between "Vaikundam Precision Components Pvt Ltd" and "Sri Vaikundam Polymers Pvt Ltd" is high — they share the distinctive token and both suffix tokens — yet they are separate legal entities with separate facilities. Meanwhile the truncated bank header scores low against its own entity. Fuzzy matching is exactly wrong in both directions on the same file.

Identifiers do not have this problem. The PAN's fifth character alone separates the two companies above: AAECV1173P (V for Vaikundam) against AAJCS4402M (S for Sri Vaikundam). One character, decisive.

How do you map period, the second axis?

Entity is only half the coordinate. Every document also has to land in the right period, and the errors here are as consequential.

• Assessment year versus financial year. An Indian ITR for AY 2025-26 reports FY 2024-25. Off-by-one on this is the most common period error in Indian credit files, and it produces a spread that looks a year fresher than it is.
• Provisional, limited-review, audited, restated. Four different documents can all claim to be "FY25". Provisional FY25 filed in April differs from audited FY25 signed in September. Both are real. Only one is the number you underwrite on.
• Restatement. The FY24 comparative column inside the FY25 audited accounts is not the same as FY24 as originally filed. If your spread pulls FY24 from the original filing in one year and from the restated comparative the next, the trend line is an artefact.
• Stub periods. A change of financial year end produces a 9-month or 15-month period. Annualising it silently distorts every ratio.
• Jurisdictional year ends. UAE and US entities on calendar years inside an Indian group on 31 March. A "FY25" label means different things in the same file.

Store the period as an actual date range with a status flag — 2024-04-01 to 2025-03-31, audited, signed 2025-09-12 — not as a label. Labels are what cause the errors. This matters directly to how the numbers line up in financial spreading.

How does the mapping actually run, step by step?

1. Build the entity register before you touch the documents. From the application, the group structure declaration and the related-party note: legal name, all known variants, PAN or EIN or TRN, GSTIN or trade licence, CIN, registered address, known bank accounts, and role — borrower, co-borrower, guarantor, promoter, non-obligor group entity.
2. Classify each file by document type first. ITR, audited financials, bank statement, GST return, bureau report, stock statement, sanction letter, board resolution. Type determines which identifiers to look for and where.
3. Extract identifiers before content. Run identifier detection with format validation — PAN pattern and status character, GSTIN checksum, CIN length and state code, TRN digit count and prefix — and capture the page and coordinate box of each hit.
4. Score against the register on identifiers. A validated identifier match is an assignment. Two identifiers pointing at different entities is a conflict, not an average.
5. Resolve the period axis independently. Read the statement header, audit report date, assessment year and account-statement date range. Record a date range and a status, never a label.
6. Apply consolidation rules. Consolidated accounts are tagged as such and excluded from any standalone roll-up. A subsidiary's standalone accounts and the parent's consolidated accounts are never summed.
7. Route what remains, with evidence. Anything with no identifier, a conflict, or an identifier that fails validation goes to an analyst — with the candidate entities ranked and the evidence visible.
8. Lock the mapping and cite it. Store the assignment, the signal that produced it, the page it came from, and who confirmed it. This is what an examiner asks about when a group exposure is questioned.

Worked example: a 20-file set for a four-entity group

The register (identifiers illustrative):

Note the fourth characters: C on three, P on the fourth. The promoter is separable from the companies before a single name is compared.

The mapping:

Eighteen files assign on a validated identifier. Two do not, and both are genuinely ambiguous rather than merely difficult.

File 18 — the stock statement. It carries no registered identifier at all, only a group letterhead. Hosur is in Tamil Nadu, which points at Opco 1, whose GSTIN state code is 33 — but Opco 2 could plausibly run a Tamil Nadu godown that has never appeared in the file. Stock statements drive drawing power, so a wrong assignment moves a live limit. There is no honest way to resolve this from the document. It goes to a person, who checks the plant list in the sanction terms or asks the relationship manager.

File 19 — the sanction letter. "Vaikundam Polymers Pvt Ltd" is not a name in the register. It is either (a) Sri Vaikundam Polymers with the honorific dropped, in which case there is an undisclosed facility to a co-borrower, or (b) a fifth group entity nobody declared. The address is Bengaluru, consistent with Opco 2's Karnataka registration, which makes (a) more likely — and makes it more urgent, not less, because an undisclosed facility to a co-borrower changes the group exposure. A fuzzy matcher would assign this to Opco 2 at high confidence and the undisclosed-facility question would never be asked. That is precisely why near-miss name matches must escalate rather than resolve.

What does the reviewer need to see to resolve it in seconds?

Not the file. The evidence.

• The candidate entities, ranked, with the reason for each — "Opco 1: state code match, 0.31 name similarity" against "Opco 2: name similarity 0.88, no state match".
• The page and highlighted box where each signal was found, so the analyst confirms rather than re-reads.
• The conflict stated explicitly. "GSTIN on page 1 resolves to Opco 1. Account name on page 3 resolves to Opco 2."
• What is already assigned to each candidate, so the reviewer sees whether this file duplicates a period already covered.
• One-click assignment with a recorded reason, feeding back into the register so the next document with that account number or name variant resolves automatically.

A reviewer with those five things resolves a file in under a minute. A reviewer handed a PDF and a dropdown does not.

How does this change across India, the US and the UAE?

India. The richest identifier environment in the world for this problem. PAN, GSTIN and CIN together give you entity type, state, registration year and tax identity, and the GSTIN embeds the PAN so two documents from different registries cross-validate. The complications are transliteration, honorifics and the density of group structures with shared promoters — see CIBIL commercial report analysis for how the bureau presents the same problem.

United States. The EIN is reliable where present but appears on fewer documents, and DBA and assumed names diverge freely from the legal name. Single-member LLCs may file on the owner's Schedule C, which is precisely the promoter-versus-company confusion above, made structural. Guarantor entity structures — trusts, holding LLCs, tenancy-in-common — add a layer.

UAE. The TRN identifies VAT-registered entities and the trade licence identifies the licensing authority, which matters because mainland and free-zone entities in the same group are separate legal persons with different regulatory footprints. Arabic and English name variants of the same entity are routine, and the English variant on a bank statement often differs from the English variant on the trade licence. YuSight's UAE support covers AECB and CBRB bureau data, VAT returns, trade licences and entity triangulation for exactly this reason.

Where does YuSight do this?

Document Intelligence auto-classifies and validates tax returns, bank statements, financial statements and bureau reports, and maps documents to the right borrower entity in multi-entity structures — before extraction, not after. Assignments carry the signal and the source page. Files that cannot be resolved on an identifier are routed rather than guessed. Extraction is measured at 95.2% accuracy against a manual benchmark, and every figure that reaches a spread or a credit assessment memo is traceable to its source document and page.

The techniques underneath the extraction step — and why the choice among them matters less than the routing around them — are covered in OCR vs IDP vs LLM extraction.

FAQ

How are documents mapped to entities in a group structure?

By extracting a machine-readable identifier from each document — PAN, GSTIN, CIN, EIN, TRN, trade licence or a registered bank account number — and matching it against an entity register built from the application and the related-party note. Names are used to rank candidates, never to decide.

What happens when names differ across documents?

Nothing, if an identifier is present, because the identifier decides. When no identifier is present the name variant becomes a reason to escalate rather than a reason to assign, since near-miss names are exactly where undisclosed entities and undisclosed facilities hide.

How is a guarantor's file linked to the borrower?

As a linked but separate node in the register, with the role recorded as guarantor. The guarantor's bureau report and personal return support the guarantee assessment; they never flow into the borrower's spread.

Why is fuzzy name matching not enough on its own?

Because it fails in both directions at once. Two different group companies sharing a distinctive token score high against each other, while a truncated bank account header scores low against its own entity.

What should happen to a document nobody can assign?

It should route to a human with the candidate entities ranked, the evidence highlighted on the page, and the conflict stated in one line. It should never be assigned on a best guess, and it should never be silently dropped.

How do you stop a promoter's personal ITR being counted as company income?

The fourth character of the PAN settles it — P is an individual, C is a company. A promoter's return is mapped to the promoter node, where it supports net-worth and guarantee analysis rather than the operating company's profit.

How do you avoid double-counting a subsidiary in consolidated accounts?

Tag consolidated statements at the point of classification and exclude them from any standalone roll-up. A subsidiary's standalone accounts and the parent's consolidated accounts describe overlapping cash, so summing them overstates the group.

How do you handle provisional versus audited financials for the same year?

Store both, with the period as a date range and an explicit status flag, and let the spread choose audited where it exists. Keep the provisional figures visible so the analyst can see how far the final numbers moved.

Does the period need to be mapped as carefully as the entity?

Yes, and it is the axis most often got wrong. An Indian ITR for assessment year 2025-26 covers financial year 2024-25, and a restated comparative is not the same figure as the original filing for the same year.

Key takeaways

• Map on identifiers, not names. PAN, GSTIN, CIN, EIN, TRN, trade licence, LEI and registered account numbers decide; names only rank candidates.
• Misassignment produces a coherent, correctly cited, wrong spread — the failure most likely to reach committee unchallenged.
• The fourth character of a PAN separates a promoter from a company before any name is compared.
• Fuzzy name matching fails in both directions: high similarity between genuinely different group entities, low similarity between a truncated bank header and its own entity.
• Period is a second axis. Store a date range and a status, never a label, and remember that assessment year 2025-26 means financial year 2024-25.
• Consolidated accounts must be tagged and excluded from standalone roll-ups, or the group double-counts every subsidiary.
• A near-miss name with no identifier is an escalation, not a match. That is where undisclosed entities and undisclosed facilities are found.

Upload a messy document set and see it classified — [book a live demo](https://yuverse.ai/yusight) with a real group borrower and watch which two files it refuses to guess on.