Live planning model
Solve one deposit stream against two wedding milestones
A plan can reach the final total yet fail an early vendor deposit. This model compounds and deposits month by month, withdraws the vendor deposit on its due month, and uses bisection to find the minimum monthly contribution that passes both tests.
| Constraint or plan line | Computed balance or saving | Required amount | Margin or difference |
|---|
Current calculation process
Formula, default substitution, intermediate quantities, and check
balance_m = balance_(m-1)(1+r) + PMT; withdraw deposit at due month; solve min PMT satisfying milestone and final target
Deposits occur at month end. The deposit is paid after that month’s growth and monthly saving. The confirmed final contribution is added only at the event horizon. A monotonic bisection solves the minimum monthly amount satisfying both inequalities.
Five-step milestone plan
Protect the deposit before the event total
- Set the final protected fund needed after all modeled early deposits have been paid.
- Enter the current dedicated balance and the exact vendor deposit due amount and month.
- Set the event horizon, conservative yield, and only a confirmed contribution arriving at the final milestone.
- Compare your planned monthly amount with the minimum that passes both constraints.
- Retain the contract payment schedule, account evidence, and exported milestone ledger; rerun after every payment or date change.
Five milestone concepts
Why a final-goal annuity is not enough
Liquidity constraint
The account must hold enough cash before the vendor withdrawal, regardless of the eventual total.
Balance recursion
Each month grows the prior balance and adds one end-of-month contribution.
Milestone withdrawal
The vendor deposit reduces the fund at its due month and changes every later balance.
Two binding tests
The minimum monthly saving is whichever requirement is stronger: early liquidity or final funding.
Bisection solver
Because both balances rise monotonically with PMT, repeated bracketing finds the smallest passing contribution without a fragile closed-form case split.
Symbols and default substitution
Follow the money month by month
| Symbol | Meaning | Default | Unit |
|---|---|---|---|
| T | Final protected fund | 42,000 | USD |
| C | Current wedding fund | 9,000 | USD |
| D | Vendor deposit | 7,500 at month 5 | USD |
| n | Event horizon | 16 | months |
| r | Monthly yield | 3.8% / 12 | decimal/month |
| PMT | Monthly end-of-month saving | solved | USD/month |
Default recursion starts at $9,000. For months 1–16, multiply prior balance by 1 + 0.038/12 and add PMT; after month 5’s deposit, subtract $7,500; after month 16, add the confirmed $3,000. The solver requires pre-withdrawal month 5 balance at least $7,500 and final balance at least $42,000.
Three cash-flow lenses
Stress the two constraints separately
Deposit-date compression
Move the due month earlier while leaving the event date fixed. The early liquidity constraint may become binding even when final funding barely changes.
Contribution certainty
Set the final contribution to zero unless its amount and timing are dependable; it cannot help the earlier deposit in this model.
Yield humility
Use zero or a conservative cash yield for money needed soon. A higher assumed return should not be used to justify a contractual payment.
Two milestone cases
Normal and invalid timing
Venue deposit before final saving
The default couple must fund a $7,500 month-5 payment and still rebuild to $42,000 by month 16. The solver reports the stronger monthly requirement and both margins.
Deposit due at the event
A due month equal to or after the event month is rejected. The sequence would no longer represent an early milestone followed by a final fund.
Terms
Milestone-savings vocabulary
- Milestone
- A dated funding requirement tested within the saving horizon.
- Liquidity
- Cash available when a contractual payment is due.
- Recursion
- Month-by-month balance update using the prior balance.
- Binding constraint
- The requirement determining the minimum monthly contribution.
- Bisection
- Repeatedly halving a passing/failing contribution interval.
- Final contribution
- Confirmed amount added only at the event horizon here.
Milestone-saving questions
Frequently asked questions
Why can the final target pass while the deposit milestone fails?
Later monthly contributions and the final contribution may fill the event fund, but they arrive too late for the early vendor payment.
When is the monthly deposit added relative to the vendor payment?
The model grows the balance, adds that month’s saving, then pays the deposit in its due month.
Why use bisection instead of one annuity formula?
The early withdrawal creates two inequality constraints. Bisection finds the minimum contribution satisfying both without assuming which one binds.
Can a final family contribution help pay the early deposit?
Not in this model. It is added only at the event horizon, so it cannot provide earlier liquidity.
What happens at zero yield?
The month-by-month recursion remains valid: prior balance receives no growth, monthly savings are added, and the deposit is withdrawn on schedule.
Can I model several vendor deposits?
Not on this page. Build a detailed cash-flow schedule when there are multiple withdrawals or irregular contributions.
Limits and evidence
Actual contracts can have more than two milestones
- The model includes one early withdrawal and one final funding target.
- Deposits and interest are monthly and occur in a fixed order.
- Yield is constant and not guaranteed; tax and account restrictions are omitted.
- Refundability, cancellation, credit-card timing, and additional vendor installments are not modeled.
Evidence record: retain signed payment schedules, deposit/refund terms, contribution confirmations, account statements, transfer records, and exported report. This is savings planning, not financial or contract advice.
Sources and related tools
Link savings to the obligation calendar
- CFPB: Your Money, Your Goals toolkit — savings and cash-flow planning tools.
- CFPB: Budgeting guidance — goal and resource tracking.