Loan document exception records across systems: a map of the loan system, e-sign, exception log and repository

Short answer

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.

Visual briefFull-size diagram
A hub-and-spoke map with the exception note at the center and four systems around it, the loan system, the e-sign account, the closing checklist and the document repository, each joined to the note by its linking key: version ID, packet ID, loan number and document type.
Illustrative system map. The exception note is the one record that should cite every other key.

This map is part of the loan document exception closure guide, 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

SystemRecordLinking keyUsual owner
Loan origination or documentation systemGenerated document versionsLoan number plus version identifierLoan documentation manager
Loan system or spreadsheetClosing checklist itemLoan number plus checklist itemPost-closing manager
E-sign accountSigning packet, recipients and event timesPacket (envelope) identifier; loan number only if entered as a custom fieldE-sign administrator in IT, used by the closing team
E-sign accountCompletion certificatePacket identifierE-sign administrator
Exception logException note with correctionException ID and loan number; should cite version and packet identifiersPost-closing manager, reporting to the lending operations head
Document management repositoryFinal signed setLoan number plus document typeRecords 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.

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.

StepRecordSystemKey that joins it to the next
1Security agreement version 1 generatedLoan systemLN-48213, version SA-v1
2Packet E-1 sent with SA-v1E-sign accountPacket E-1, custom field LN-48213
3Entity name corrected; SA-v2 generatedLoan systemLN-48213, version SA-v2
4Customer signs SA-v1 in E-1E-sign recipient eventsPacket E-1 event time
5Checklist item fails; exception EX-2291 openedChecklist and exception logEX-2291 cites LN-48213, SA-v1 and E-1
6Packet E-2 sent with SA-v2 and signedE-sign accountPacket E-2, custom field LN-48213
7EX-2291 closed citing SA-v2 and E-2Exception logCorrection reference E-2
8Signed SA-v2 filed; SA-v1 kept as an earlier signed copyRepositoryLN-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.

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.

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.

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 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, check the lender on who qualifies and read the program terms before introducing its lending operations head.

  1. Step 1Share your linkSend your personal link to a company you know.
  2. Step 2Company appliesThe company applies itself at /apply.
  3. Step 3Company signs and is paidThe company signs, delivers its data and is paid by SourceX under its agreement.
  4. Step 4You get your rewardYour 25% of the actual supplier payout. A reward becomes payable after SourceX has paid the referred company under its signed agreement and the payout conditions in the program terms are met, including finance approval and your tax and payment details.

Common questions

Can the loan number alone rebuild an exception?

It finds the right file, but not the right moment. A loan can have several versions of one document and several signing packets, so the version identifier and the packet identifier are what tie a correction to the specific mismatch it fixed.

What if signing packets were never tagged with the loan number?

The chain can often still be joined through the exception note, the recipients and the timestamps, but with less certainty. Record that as the open question rather than guessing how many cases will match.

Should I ask for an e-sign export to check the keys?

No. Ask the e-sign administrator which fields each packet carries and whether certificates are kept. Field names and counts are enough for a map; documents and customer details never pass through the partner.

Sources

  1. refer.sourcex.si/terms
  2. law.cornell.edu/uscode/text/15/7001
  3. support.docusign.com/s/document-item

Free resources

Know a company with valuable proprietary data?

Become a referral partner, get your link and introduce the company’s CEO (in an owner-run company, usually the owner). Referral partners can join from most countries. We can't work with partners in countries or regions under U.S. sanctions or on U.S. restricted-party lists. The companies you introduce should be based in the U.S., Canada and the EU, or in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia with at least 90% of their data in English.

Refer a company →

I own a business

Explore licensing your company's data directly to SourceX for AI training and evaluation. Start a short assessment; no uploads needed.

Start an assessment