When you record a promissory note or income-producing deployment that's been active for a while, the early periods are already history. Backfilling lets you fill in those past payments or distributions in one operation — the banking ledger, deployment cash flow history, and (for notes) payment status all update together.
Policy Stack offers two backfill flows, depending on whether the deployment has a payment schedule:
- Backfill panel — for fully-amortizing and interest-only-balloon notes, which have a generated schedule of past-due rows
- History repair panel — on the asset detail page for cadence-based history: pro-rata distribution notes, real estate, dividends, and "other" income-producing deployments
Both flows appear in Asset Workspace → Payment Tracking when there is something to catch up on. There is no separate note-detail workspace.
Backfill Panel — Scheduled Notes
The Backfill panel surfaces in Asset Workspace → Payment Tracking when the generated schedule has rows whose due date is in the past and whose status is still "scheduled" (i.e., not yet recorded as paid).
You'll see it in two common situations:
- Adding an in-progress note — you bought the note from another party, or you set up tracking after the note had been originating payments for a few months. The wizard creates the full schedule, but the early periods are already history.
- A gap in entries — you missed recording payments for a while, and the schedule has accumulated past-due rows.
- Open the note — navigate to Capital → Notes and click the note (or open it from its parent deployment / asset page)
- Find the Backfill panel — it appears in Payments only when there are past-due scheduled rows
- Review the list — every scheduled payment with a past due date is listed, with its date and expected amount
- Confirm the totals — verify the per-row amounts match what was actually received. If a real payment differed from the scheduled amount, adjust before confirming.
- Click Confirm Backfill — Policy Stack records each row as paid, writes the matching cash flow entries to the deployment, and inserts the banking ledger rows in a single operation
History Repair Panel — Cadence-Based Deployments
Some deployment types pay out on a cadence but don't generate a row-by-row payment schedule. For those, Policy Stack derives the missing periods from the deployment's start date and cadence, then lets you review them on the asset detail page.
Supported deployment types:
- Pro-rata distribution notes — payments based on principal recovery, not a fixed schedule
- Real estate — rent or NOI distributions
- Dividends — recurring dividend payouts
- Other — any deployment classified as "other" with a configured cash-flow cadence
Supported cadences: monthly, quarterly, semi-annual, and annual. The history repair panel lists one row per missing period (e.g., monthly cadence with a 6-month gap shows 6 rows), pre-filled with the deployment's expected cash flow amount.
- Open the asset — go to Capital → Assets and open the deployment. From a pro-rata note, use Manage cash-flow history to reach the same page.
- Set the review range — use From, To, and Amount / period. Changing the range generates cadence-aligned periods even when they were not visible when the page opened.
- Review each period — choose Record, No activity, or Skip. Record rows can be edited; No activity creates an explicit gap; Skip creates no write.
- Record history — confirm the selected rows. Existing or newly recorded periods are protected by server-side conflict checks, and any stale conflicts remain visible for review.
The history repair flow caps a single backfill at 120 rows (10 years monthly, 30 years quarterly, or 120 years annually).
What Backfill Writes
A single backfill operation writes to multiple places at once:
- Note payment status (scheduled-note panel only) — each previously-scheduled row is marked paid with its due date as the payment date
- Deployment cash flows — a cash-flow row is added to the deployment for each backfilled period, categorized appropriately (interest income, principal return, rent, dividend, etc.)
- Banking ledger — every backfilled row gets a corresponding ledger entry, tagged so it's distinguishable from in-the-moment recordings
The ledger rows carry an actual_backfilled source tag rather than the regular "actual" tag, so you can tell at a glance which entries came from a backfill vs. which were recorded as they happened. This matters for audit trails and for understanding aggregate metrics — backfilled rows count toward your income totals, but the tag preserves the distinction.
Routing Applies to Backfilled Payments
If the note has proceeds routing configured (interest or principal slices going to a policy loan or PUA deposit), the routing applies to backfilled payments the same way it would to live ones.
That means a backfill on a note with 50% interest → loan repayment sends 50% of every backfilled interest payment as a loan repayment, generating a chain of loan repayment ledger entries dated to each historical period. If you want to record the history without triggering those routing actions retroactively, edit the note's routing to 0/0/100 (all cash) before backfilling, then restore the routing afterward.
What Backfill Does Not Do
- It doesn't update past net worth snapshots. Snapshots are point-in-time records of what the data looked like on the snapshot date; backfilling does not retroactively change them.
- It doesn't try to split payments. Each row backfills at its listed amount. If an actual payment differed, edit the row before confirming.
- It doesn't write a separate "backfill event" log. The ledger tag and batch metadata are the audit trail; there is no parent user-facing event beyond the individual entries.
After a Backfill
Once the backfill is recorded, normal flow resumes:
- New cash flows continue arriving on the deployment's cadence
- You record them one at a time as they actually arrive (via Record Cash Flow on the deployment, or the scheduled-payment flow on the note)
- The Backfill panel or history repair panel stays hidden until a new past-due period accumulates (which shouldn't happen for an actively-maintained deployment)