Guide · Errors
The ten most common loan boarding errors
Boarding errors are not random. They cluster in the few percent of a closing package that changes from loan to loan, they come from the same handful of causes, and each one has a specific check that would have caught it before the core. These are the ten we see most, where each one lives, and the rule that catches it.
By the Bookend team8 min read
Photo: Mikhail Nilov / PexelsA note on evidence: these are the error families the Bookend rule catalog exists to catch, drawn from how commercial closing packages are actually assembled and boarded. We do not publish frequency or cost figures until we have measured pilot data. A Closing Workflow Review pulls three of your recent exceptions, which is the only sample that matters for your bank.
1. Rate, index, and margin disagreement
Where it lives: Note vs. loan agreement vs. boarding sheet vs. approval
The note was redrawn after a rate change, and the summary sheet or the approval record was not. A variable-rate loan boarded as fixed, or with the wrong index or a missing floor, misbills from the first cycle.
How to catch it before the core: Compare the rate on every document that states it, and compare the index, margin, floor, and ceiling separately. Tolerance on rate should be zero. Treat any difference as an exception and cite each source.
2. Maturity date and term that do not agree
Where it lives: Note vs. approval vs. boarding sheet
The term is expressed in months on the approval and as a date on the note. A first payment date shifts the maturity. A balloon is boarded as fully amortizing.
How to catch it before the core: Derive the term from the note date and maturity date and compare it with the approved term. Check the first payment date against the payment schedule.
3. Payment schedule and interest method
Where it lives: Note vs. boarding sheet vs. core defaults
Actual/360 on the note, 30/360 by default on the core product code. Monthly on the note, quarterly on the sheet. The core accepts either without complaint.
How to catch it before the core: Reconcile frequency, amount, interest method, and amortization explicitly. Never let the product code’s default stand in for the note.
4. Borrower name and entity
Where it lives: Note vs. guaranties vs. CIF record
“Example Holdings LLC” on the note, “Example Holdings, L.L.C.” on the CIF, and a DBA on the approval. The loan lands on the wrong CIF or creates a duplicate.
How to catch it before the core: Normalize names before comparing and flag whatever differences remain. Confirm the CIF match before the record is staged.
5. Guarantor set
Where it lives: Approval vs. executed guaranties
The approval names three guarantors, but the package holds two executed guaranties, or one of them is unsigned. The loan is boarded with recourse the bank does not actually have.
How to catch it before the core: Presence rule: every guarantor on the approval has an executed guaranty in the package, and every guaranty in the package names a guarantor on the approval.
6. Collateral coding and lien position
Where it lives: Security agreement or mortgage vs. boarding sheet vs. core collateral codes
Real estate boarded under the wrong collateral code. A second lien boarded as a first. A secured loan boarded with no collateral record at all. Call report and risk-weighting problems follow.
How to catch it before the core: Presence rule: collateral exists when the loan is secured. Compare type and lien position against the security document, and map to the core code through a versioned field map rather than from memory.
7. Disbursement math
Where it lives: Disbursement request and authorization vs. note vs. fee schedule
Disbursements that do not sum to principal net of fees. A fee on the approval that is missing from the settlement. A payoff figure that changed between the approval and the closing date.
How to catch it before the core: Arithmetic rule: the sum of disbursements plus fees equals principal, within a stated tolerance, and fees on the approval appear on the settlement.
8. Product, GL, officer, branch, and call code
Where it lives: Approval vs. boarding sheet vs. core
Bank-internal coding is not on any executed document, so it gets keyed from a sheet or from habit. The core cannot tell a wrong code from a right one. Reporting can, months later.
How to catch it before the core: Carry the coding on the approval record profile, map it through the field map, and preview the boarding record against a real loan before the map goes live.
9. Execution gaps
Where it lives: Every executed document
A missing signature page, a blank initial box on a rider, an empty notary acknowledgment, an undated signature. Boarding does not look for these and funding does not wait for them, so the gap is found by audit or when the loan defaults.
How to catch it before the core: Verify signature, initials, date, and notary presence by document type against the bank’s execution templates, and block approval until each gap is resolved with a reason.
10. Boarding twice, or not at all
Where it lives: Core commit
A timeout on the first post and a retry that creates a duplicate account. Or a boarding file that was generated and never uploaded.
How to catch it before the core: Commit once, and make the commit resumable. On a duplicate, inquire instead of posting again. Record the core’s answer verbatim on the loan.
The pattern behind the ten
Look down the list and the checks fall into four kinds. Agreement rules compare the same term across documents and the approval. Arithmetic rules check that figures that must add up actually do. Presence rules check that a document exists when something else implies it should. Execution templates check that each document carries its marks. All four are deterministic: the same package and the same rules version give the same findings. That is what makes a finding defensible to an auditor, and safe to tune by policy rather than by retraining a model.
That is also how loan boarding automation is designed in the Bookend platform. A model locates the values, versioned rules judge them, and a person decides every exception before a second person approves the boarding.
Run the checks by hand first
The Commercial Loan Boarding Checklist lists these checks by document in the order they should run. Many banks use it to tighten their existing post-closing QC before deciding whether to automate.
Questions
Boarding errors FAQ
Why do loan boarding errors happen?
The variable terms are spread across seven or eight documents plus the credit approval, and a person compares and re-keys them by hand on every loan. Most of the package is boilerplate. The few percent that varies (rates, dates, amounts, parties) is where cross-document disagreements, transposition errors and stale approval terms hide. Execution gaps, such as missing signatures, initials or notary blocks, are a second family of errors that usually surface only after funding.
Does the software board loans automatically?
No. The software does the comparing and the keying. Your people keep the judgment and the approvals. Every loan passes through a review workstation where a closing specialist accepts, overrides or escalates each finding with a reason code. Boarding and funding are two-phase: the person who stages a record can never approve it. Nothing is committed to the core and no wire request is released without that second approval.
What does the examiner get?
A per-loan evidence packet as PDF and JSON: document hashes, every extracted value with its source page and position, findings and how each was resolved with reason codes, approvals with who and when, boarding and funding events, and the result of verifying the hash chain. Change one byte in the database and verification fails at that link.