Legacy Reconciliation

When the double-entry ledger was introduced, every historical SPV already had years of investments, payments, and bank transactions. The legacy reconciliation process (also called "bootstrap") retroactively created ledger entries for all of this existing data so that every SPV — old and new — has a complete, auditable financial record.

What Happened During Bootstrap

The bootstrap ran automatically for each SPV that had investments. It worked through five layers, in order:

Layer 0: Account Provisioning

The system created the standard set of ledger accounts for each SPV and each investment within it — operating cash, investor capital, commitment receivables, fee income, and so on. These are the same accounts that new SPVs get when they're opened today.

Layer 1: Commitments and Payments

For every investment, the system recorded:

• A commitment entry establishing how much the investor agreed to invest
• A payment entry for each completed payment, reducing the investor's obligation and increasing SPV cash
• A reversal entry for any returned payments (e.g. ACH returns)

This used the exact same recording logic as the live platform, just called retrospectively.

Layer 2: Bank Statement Enrichment

For bank transactions that were already matched to a payment, the system annotated the corresponding ledger entry with bank statement metadata — the actual amount received, the statement date, and the last four digits of the account number. This supports audit and reconciliation review.

Layer 3: Unmatched Bank Transaction Classification

Bank transactions that weren't linked to any payment went through a classification engine:

1. Exact match — amount and date match an unlinked payment? Link them.
2. Fuzzy match — amount is within $50 (typical wire fee variance) and dates are close? Link them with a lower confidence flag.
3. Distributions — money sent from the SPV to the portfolio company is recorded against the SPV's Portfolio Investment account.
4. Cross-SPV transfers — a debit from one SPV and a matching credit to another? Recorded against each SPV's Intercompany Transfers account.
5. Heuristic classification — reserved for future pattern matching.
6. Suspense — anything remaining goes into the SPV's own reconciliation suspense account for manual review.

Layer 4: Commitment Balancing

After all cash entries were created, the system verified that each fully-funded investment's receivable balance was zero. If small discrepancies existed (e.g. from rounding or partial payments recorded differently), a balancing adjustment was created automatically.

What "Suspense" Means

Each SPV has its own reconciliation suspense account (code 9900.SPV-{id}). Items in this account are bank transactions that the system couldn't automatically classify. They represent real money that moved through that SPV's bank account, but the system needs a human to determine what they were for.

Common reasons a transaction ends up in suspense:

• A wire payment with no matching investment (investor may have used the wrong reference)
• A bank fee or interest payment
• A distribution or return of capital that predates the current system
• An unusual one-off transaction

See the Resolving Ledger Suspense playbook for step-by-step instructions.

How to Tell if a Legacy SPV Is Healthy

After bootstrap, each SPV's reconciliation report indicates whether it's "healthy":

• Healthy — all receivables are balanced, no items in suspense
• Needs review — there are suspense items or unbalanced receivables that require admin attention

You can review this in the admin panel under the SPV's ledger section.

Important Notes

• The bootstrap process is idempotent — running it again on the same SPV produces no duplicates or errors.
• Legacy entries are tagged with source: migration so they can be distinguished from live entries.
• All accounts are scoped to their SPV, including suspense. This means each SPV's trial balance is self-contained and should balance independently.