# Loan exception records: system map | SourceX

Canonical: https://refer.sourcex.si/guides/loan-document-exception-closure-records-across-systems
Last updated: 2026-10-19

Three keys rebuild a loan document exception across systems: the loan number, the document version identifier and the e-sign envelope identifier. The exception note is the bridge, because it is the one record that should cite all three. Around it sit four systems: the loan origination or documentation system, the e-sign account, the closing checklist and the document management repository. If one key was never written down, or lived only in a system being retired, the correction no longer points to the problem it fixed.

This map is part of the [loan document exception closure guide](/guides/workflow-loan-document-exception-closure), which covers what to list before document systems are merged. Here the job is narrower: name the system that holds each record, the field that joins it to the next, and who owns it, so a document automation consultant can describe a lender's evidence without touching any of it.

## Four systems, one closing: where each record sits

**Loan origination or documentation system.** Generates each document from a template and, in many setups, keeps a version history: amount, template, version number and timestamp. This is the "before and after" of any change. Whether earlier versions are retained or overwritten on regeneration differs by system and configuration, so it is the first thing to confirm.

**E-sign account.** Holds each signing packet (an envelope, in most e-sign products), its recipients and the time of every event, usually summarized in a completion certificate. The packet's own identifier is the native key here; the loan number is present only if someone put it there.

**Closing checklist.** Lives in the loan system or, at many lenders, in a spreadsheet. It lists each required item and its status. It records that an item was complete, and rarely says how it became complete.

**Exception log.** A tracking module or a log that records the exception type, when it was opened, the correction and when it closed. Its quality varies more than any other record here: some lenders keep structured fields, others a free-text line per item.

**Document management repository.** Holds the final signed set, filed by loan number and document type. It proves what was signed, not when or why it was signed twice.

## System, record, linking key and owner

| System | Record | Linking key | Usual owner |
|---|---|---|---|
| Loan origination or documentation system | Generated document versions | Loan number plus version identifier | Loan documentation manager |
| Loan system or spreadsheet | Closing checklist item | Loan number plus checklist item | Post-closing manager |
| E-sign account | Signing packet, recipients and event times | Packet (envelope) identifier; loan number only if entered as a custom field | E-sign administrator in IT, used by the closing team |
| E-sign account | Completion certificate | Packet identifier | E-sign administrator |
| Exception log | Exception note with correction | Exception ID and loan number; should cite version and packet identifiers | Post-closing manager, reporting to the lending operations head |
| Document management repository | Final signed set | Loan number plus document type | Records manager |

The owner column matters later. Each of these people can confirm a field exists; none of them, by holding the system, can decide whether the lender discusses licensing its records. That question is covered in the [who can license decision tree](/questions/who-can-license-loan-document-exception-closure-records).

## One fully joined correction (Illustrative)

Invented for this page. A fictional 320-person commercial lender closes a term loan, LN-48213. After the package is sent, credit review corrects the customer's legal entity name on the security agreement. The customer has already signed the first version.

| Step | Record | System | Key that joins it to the next |
|---|---|---|---|
| 1 | Security agreement version 1 generated | Loan system | LN-48213, version SA-v1 |
| 2 | Packet E-1 sent with SA-v1 | E-sign account | Packet E-1, custom field LN-48213 |
| 3 | Entity name corrected; SA-v2 generated | Loan system | LN-48213, version SA-v2 |
| 4 | Customer signs SA-v1 in E-1 | E-sign recipient events | Packet E-1 event time |
| 5 | Checklist item fails; exception EX-2291 opened | Checklist and exception log | EX-2291 cites LN-48213, SA-v1 and E-1 |
| 6 | Packet E-2 sent with SA-v2 and signed | E-sign account | Packet E-2, custom field LN-48213 |
| 7 | EX-2291 closed citing SA-v2 and E-2 | Exception log | Correction reference E-2 |
| 8 | Signed SA-v2 filed; SA-v1 kept as an earlier signed copy | Repository | LN-48213, security agreement |

Read across the key column and the chain holds: two versions, two packets, one exception that names both sides. Remove any one key and the picture changes. Without step 5's citations, E-1 looks like an abandoned packet. Without the earlier SA-v1 in step 8, the repository shows one clean signature and nothing explains the extra envelope. A different hard case, a guaranty signed after the note changed, is told decision by decision in the [exception examples](/guides/loan-document-exception-closure-exception-examples).

## Where the joins break during a migration

**Version history overwritten.** If regeneration replaces the earlier document, step 1 disappears and the exception has no "before".

**Packets named by customer and date.** Without the loan number on the packet, steps 2 and 6 can only be matched by recipient and timing. Docusign lets account administrators set up envelope custom fields, as free text or a list of values, required or optional, and states that those fields and values are included in the Certificate of Completion. A lender that made a loan number field required has a much stronger join than one that relied on subject lines. Ask which applied, and from which year.

**Certificates left behind.** A migration that moves only signed PDFs drops the event history, and with it the order in which people signed. Federal e-signature law lets an electronic copy satisfy a retention requirement only if it accurately reflects the record and stays accessible, in a form that can be accurately reproduced, for the required period (15 U.S.C. 7001(d)); whether event histories fall inside a lender's retention rules is for its counsel, but the question belongs on the map.

**Free-text exception notes.** A note that says "re-signed, cleared" names neither version nor packet. The chain then rests on dates.

**Duplicate removal in the repository.** Rules that keep only the latest signed copy of each document type delete the earlier signature that explains the exception. The same pattern in purchasing is covered in [assessing procurement approvals and exception workflows](/guides/how-to-assess-procurement-approvals-and-exception-workflows).

## Questions that fill the map at metadata level

Put these to the lending operations head or post-closing manager. Each asks about a field, never a file.

1. Does the loan system keep every generated version, and since when?
2. Do signing packets carry the loan number in a custom field, a subject line or not at all, and was the field required?
3. Are Certificates of Completion retained, and for which accounts and years?
4. Does each exception entry cite a document version or packet, or only the loan number?
5. Is the checklist in the loan system or a spreadsheet, and were older years kept?
6. Will the repository migration keep earlier signed copies or only the latest one?

Write "unknown" until the administrator confirms an answer; export capability in particular should never be assumed. Lenders that also hold credit memos may have related decision records, described on the [credit memo data page](/data-types/credit-memo-commercial-lending).

## Who owns the map, and what SourceX still has to review

The map describes fields and owners. It does not settle rights. Closing files contain customer information, and the lender's agreements and privacy obligations decide what could ever be included; [why data rights matter](/proof/why-data-rights-matter) explains why SourceX reviews that first.

The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting introductions; the first valid introduction within the 90-day window is credited when the company submits a verified application. Buyer interest, the rights result, the de-identification needed and any offer stay unknown until SourceX reviews the opportunity.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If the map shows a lender whose exception notes still join versions to signing packets, [register as a partner](/register), check the lender on [who qualifies](/who-qualifies) and read the [program terms](/terms) before introducing its lending operations head.

## Sources

- https://refer.sourcex.si/terms
- https://www.law.cornell.edu/uscode/text/15/7001
- https://support.docusign.com/s/document-item?language=en_US&bundleId=gbo1643332197980&topicId=ywu1578456351241.html