Student Loan Strategy: Income-Driven vs Standard Repayment in 2026

General
1

Hey everyone! I’m trying to wrap my head around the student loan repayment changes happening in 2026 and figure out the best way to model different scenarios in Beancount.

Here’s my situation: I’ve got about $45,000 in federal student loans (three separate loans with different interest rates between 4.5% and 6.8%), and I’m currently on the standard 10-year repayment plan. But with all the changes coming - SAVE being replaced by RAP, PAYE and ICR sunsetting by 2028 - I’m wondering if I should be modeling different repayment strategies.

From what I’ve read, the new RAP plan calculates payments based on adjusted gross income with a tiered percentage system (1% of income if you make $10-20k, up to 10% if you make $100k+). But the forgiveness timeline is now 30 years instead of 20-25, AND forgiveness becomes taxable income again starting this year.

So I’m trying to build out a few scenarios in Beancount:

  1. Standard repayment with the new term adjustments (my $45k balance would now be a 20-year term apparently?)
  2. RAP with minimum payments to see total paid over 30 years
  3. Standard payments with extra principal to pay off faster
  4. Hybrid approach - RAP now while income is lower, switch to aggressive payoff later

Has anyone set up a good structure for modeling multiple loan repayment scenarios? I’m comfortable with the technical side (DevOps background), but I want to make sure I’m capturing the right data points - principal vs interest breakdown, projected balances, potential tax bomb from forgiveness, etc.

Any examples of how you’ve structured your chart of accounts for student loan tracking would be super helpful!

2

This is exactly the kind of analysis I live for. The math on RAP vs standard repayment has shifted dramatically with the 2026 changes, and running the numbers in Beancount gives you a huge advantage over the online calculators.

Here’s how I’ve structured my student loan tracking (paid mine off last year, but the framework still applies):

; Separate liability accounts per loan for granular tracking
2020-01-01 open Liabilities:Loans:StudentLoans:Loan1-Subsidized USD
2020-01-01 open Liabilities:Loans:StudentLoans:Loan2-Unsubsidized USD
2020-01-01 open Liabilities:Loans:StudentLoans:Loan3-GradPlus USD

; Interest expense tracking
2020-01-01 open Expenses:Interest:StudentLoans USD

; Principal reduction tracking (helpful for scenario comparison)
2020-01-01 open Expenses:DebtPayoff:StudentLoans:Principal USD

For scenario modeling, I run separate projection files. The key insight: you need to track total cost, not just monthly payment.

Let me run your numbers:

Scenario 1: New Standard (20-year term for $45k)

  • Monthly payment: ~$300-320 (depending on blended rate)
  • Total paid over 20 years: ~$72,000-77,000
  • Interest cost: ~$27,000-32,000

Scenario 2: RAP at $81k income (median US household)

  • Monthly payment: $440 (per the new tiered formula)
  • 30-year forgiveness timeline
  • Total paid if no forgiveness: ~$158,400
  • Plus tax bomb on forgiven balance (taxable income in year 30)

Scenario 3: Aggressive payoff (your current 10-year rate + extra)

  • Monthly payment: $500-600
  • Payoff in 7-8 years
  • Total interest: ~$12,000-15,000

The FIRE angle: At your balance and what I assume is a tech salary, aggressive payoff almost always wins. The psychological weight of debt clearance is real, and you eliminate 30 years of tracking overhead.

For the tax bomb calculation, I add this projection:

; Estimated forgiveness tax liability (run in separate projection file)
2056-01-01 * "Student Loan Forgiveness Tax Bomb" #projection
  Expenses:Taxes:FederalIncome:StudentLoanForgiveness  12000 USD
  Liabilities:Loans:StudentLoans:Loan1-Subsidized      -45000 USD
  ; Assumes 24% bracket on forgiven amount

The math changed with taxable forgiveness returning. For most people earning decent income, RAP is now a worse deal than before.

3

Welcome to the rabbit hole of debt modeling! I went through something similar when I was paying off my own loans a few years back, and I’ll share what worked for me.

First, I want to second @finance_fred’s point about tracking total cost, but I’d add one more dimension: track your opportunity cost too. The money you put toward loans could be invested, and that matters for the full picture.

Here’s a simpler starting structure that I recommend for beginners before getting too fancy:

; Start simple - you can always add complexity later
2026-01-01 open Liabilities:StudentLoans USD
2026-01-01 open Expenses:Interest:StudentLoans USD

; A typical monthly payment
2026-02-15 * "Navient" "Student loan payment"
  Liabilities:StudentLoans          380.00 USD ; principal portion
  Expenses:Interest:StudentLoans     70.00 USD ; interest portion  
  Assets:Checking                  -450.00 USD

The key thing I learned: don’t try to build the perfect tracking system before you start. Get your loans into Beancount with current balances, track a few months of payments, and THEN build out your projection models.

For the scenario comparison, I actually keep a separate file called projections.beancount that I don’t include in my main ledger. It lets me play with “what if” scenarios without polluting my actual transaction history:

; projections.beancount (not included in main ledger)
; Scenario: Aggressive payoff with  extra/month

2026-03-01 * "Projected: Aggressive payoff"
  Liabilities:StudentLoans:Projected  -650.00 USD
  Assets:Checking:Projected           -650.00 USD

; Run bean-query to see projected payoff date

One thing about the hybrid approach you mentioned - it’s actually pretty smart. RAP while your income is lower (especially if you’re early career or expecting a job transition) gives you cash flow flexibility. Then when income stabilizes, you can switch to aggressive mode.

The transition deadline to watch: if you’re on any current IDR plan, you need to decide by July 2028 whether to move to IBR or RAP. That gives you time to see how your income trajectory looks.

Don’t let the complexity freeze you. Start tracking, run the numbers in 6 months, and adjust. That’s the beauty of Beancount - you can always refactor your accounts later!

4

Great discussion here. I’ll add a practical workflow angle since I help several clients track their student loans.

One thing that trips people up: your loan servicer statement doesn’t always clearly break out principal vs interest. You often get a single payment amount and have to dig into the details. Here’s my workflow for accurate tracking:

  1. Download the monthly statement (most servicers have PDFs or CSV exports)
  2. Find the interest accrual line - this tells you exactly how much interest was charged
  3. Calculate principal = Total payment - Interest charged
  4. Record the transaction with both amounts

For clients with multiple loans at different rates, I use metadata to track each loan’s details:

2026-01-01 open Liabilities:StudentLoans:Loan1 USD
  servicer: "Navient"
  original-balance: 15000
  interest-rate: 4.5
  loan-type: "Subsidized"

2026-01-01 open Liabilities:StudentLoans:Loan2 USD
  servicer: "Navient"  
  original-balance: 18000
  interest-rate: 6.8
  loan-type: "Unsubsidized"

2026-01-01 open Liabilities:StudentLoans:Loan3 USD
  servicer: "Navient"
  original-balance: 12000
  interest-rate: 5.3
  loan-type: "GradPlus"

This metadata becomes really useful when you run queries. For example, to see total interest paid on your highest-rate loan:

bean-query main.beancount "SELECT sum(position) WHERE account ~ 'Interest' AND ANY_META('loan') = 'Loan2'"

For the scenario modeling @finance_fred mentioned, I’d also suggest tracking your interest rate as of each payment date using metadata. With all the rate environment changes, having that historical record helps if you ever need to verify servicer calculations.

One more practical tip: set up a recurring reminder to reconcile against your servicer’s online portal monthly. I’ve caught errors in servicer calculations more than once. When you’re tracking in Beancount, you have the receipts to dispute.