Choosing planning software in 2026: a working advisor's framework.

I'm going to write this post the way I wish someone had written it for me eight years ago, when I was choosing a planning tool for a real practice and the vendor demos were all telling me the same things.

Most of what gets written about planning software is some combination of three things: a vendor explaining why their tool is good, a marketing comparison that is paid for in one direction or another, or a forum thread where everyone is talking about the dashboard look-and-feel. Almost nothing gets written about the actual evaluation question — what do you, a working advisor, need this tool to do for you and your clients?

So this is the version of that post.

Up front: I run Foundry Planning. The post you are reading sits on Foundry's marketing site. I am going to mention Foundry once or twice in context. I am also going to be specific about what Foundry does not do, what other tools do better, and where the choice between tools is genuinely a choice rather than a sales argument. If you read a single line in this post that feels like a pitch, I have failed at my own brief.

The conversation that's broken

Vendor demos are designed to show what the tool looks like. Working advisor evaluations need to show what the tool computes. These are not the same thing, and they tend to share very little overlap.

A tool can have a beautiful UI, a smooth client-facing report, and a polished proposal generator — and still be approximating the answer to the most expensive question the client is going to ask. Conversely, a tool can be plain to look at and computationally correct, and feel "less impressive" in a demo while being significantly better in the room.

The way to evaluate planning software is to evaluate the computation. The visuals are downstream of the computation. The proposal is downstream of the computation. If the computation is right, you can adapt the visual layer. If the computation is approximate, no amount of UI polish fixes it.

Seven dimensions that actually matter

Here is the framework I'd use today, in roughly the order they tend to matter:

1. Calculation paradigm: portfolio-led or cash-flow-led

The single most consequential dimension is what kind of model is at the center of the tool. Cash-flow planning and portfolio modeling produce different conversations with clients, and the choice of paradigm tends to be baked into the tool early enough that it shapes everything downstream.

Portfolio-led tools (a category that includes most tools that grew out of the goals-based / probability-of-success era) treat the plan as a portfolio model with cash-flow features bolted on. Cash-flow-led tools treat the plan as a year-by-year cash-flow model with portfolio features bolted on. Hybrids exist; many of them do one paradigm well and approximate the other.

The right paradigm depends on your practice. If you mostly work with accumulators twenty years from retirement, the portfolio paradigm is sufficient and the cash-flow detail is overkill. If you mostly work with clients near or in retirement — where every year is a specific decision about a specific account — the cash-flow paradigm is essential and the portfolio paradigm misses the question.

Most of the working-advisor frustration with planning tools traces back to a paradigm mismatch: a cash-flow-shaped practice using a portfolio-shaped tool, or vice versa. The translation cost between the tool's frame and the conversation's frame becomes the work.

2. Tax-engine fidelity

The tax engine is where most planning tools quietly approximate. Things to ask, with specific examples:

• Does the federal tax engine compute AMT correctly under the household's actual deduction stack?
• Does it compute QBI thresholds for pass-through clients?
• Does it model state tax independently, with the right state-specific rules?
• Does it round-trip Social Security taxability through provisional income correctly?
• Does it project IRMAA premiums two years forward against the tax engine's MAGI output — or does it use a separate income figure?
• When a Roth conversion is added to the plan, does the marginal-rate calculation for that year update? Does the IRMAA bracket two years forward update? Does the AMT calculation for that year reflect the conversion?

These are not edge cases. These are the questions where the wrong answer costs the client money. A tax engine that gets them right is doing real work; an engine that gets them approximately right is producing a recommendation that looks defensible and, in some cases, isn't.

3. Recompute speed

This is more important than it sounds.

In a kitchen-table meeting, the difference between a tool that recomputes the full plan in under a second on every keystroke and one that takes twenty seconds to refresh after each input change is the difference between a planning conversation and a data-entry session. The clients can feel the lag. They check out, they stop volunteering "what if" questions, the meeting becomes about getting through the inputs rather than about exploring the plan.

When evaluating, change a meaningful input — a retirement age, a withdrawal amount, an inflation assumption — and watch what happens. If the rest of the plan updates instantly, the tool is computing in real time. If there's a noticeable wait, the tool is doing some kind of batch recompute, and that's going to show up in every meeting.

4. Client-facing readability

The tool produces some kind of client-facing artifact: a one-page summary, a multi-page report, an interactive view. The question is whether that artifact reads, to the client, like a story they can follow.

This is where the visual layer matters — not because pretty equals good, but because clarity equals communication. A report that requires the advisor to translate every page in real time is a report that's working against the conversation rather than for it.

Test by asking: can the client read the summary alone, after the meeting, and reconstruct the plan? If yes, the report is doing real work. If they need the advisor to interpret it, the report is decorative.

5. Workflow shape

This is the dimension vendors least like to talk about. Every tool has a workflow shape — the order it expects you to enter inputs, the order it expects you to make decisions, the order it presents outputs. The shape is opinionated, even when the vendor doesn't admit it is.

Match the tool's workflow shape to your practice's workflow shape, or you will spend half your time fighting the tool. Specifically: does the tool let you build a plan in the order a planning conversation actually happens? Or does it require a complete data set before any output is meaningful?

Tools that require a complete dataset upfront tend to be heavy at the front of the engagement. Tools that produce meaningful output at every stage of input tend to be lighter, more iterative, and better suited to the way most working advisors actually have planning conversations.

6. Data import and switching cost

If you're considering a switch, the import path is real work. Evaluate honestly:

• What client data can the new tool ingest from your current one? In what format?
• For data that doesn't import directly, what's the per-client labor to recreate?
• Are the assumptions and scenario structures portable, or do they have to be rebuilt?

Most tools have an import story. Most import stories are partial. The first few clients on a new platform will take meaningfully longer than the established platform's average. Plan for that, both as time and as transition risk.

7. Pricing model

Per advisor, per firm, per plan, per client — every vendor charges differently. The right way to compare is on total cost at your actual practice size and growth trajectory, not on the headline price.

Watch for: tiered features that gate the parts of the engine you actually need behind higher tiers; per-plan or per-client fees that scale with practice growth rather than with advisor count; "premium" tax engine modules sold as add-ons. The cleanest pricing models tend to be flat per-advisor with everything included.

Three category sketches

These are blunt category descriptions; every vendor in each category has its own particulars.

Goals-based / probability-of-success tools

The classic example here is the MoneyGuide-era tool, and the category is shaped by it. Strong portfolio modeling, opinionated about goals-based framing, optimized for the planning-as-probability conversation. The cash-flow detail is layered on top of a portfolio engine, and depending on the year the tool was built, the cash-flow layer ranges from "real" to "cosmetic."

Where these tools earn their keep: practices that are genuinely goals-and-probability-shaped, with accumulators or near-retirees who think about their plan as "what's my probability of success."

Where they stop being the right tool: practices that have a lot of high-detail cash-flow conversations — Roth conversions sized to specific brackets, year-by-year withdrawal sequencing, IRMAA-aware planning. The portfolio frame doesn't bend to the cash-flow questions cleanly, and the translation cost shows up in the meeting.

Cash-flow-detail-heavy tools

The classic example here is the eMoney-era tool. Strong on data aggregation, strong on cash-flow detail, strong on the volume of inputs the tool can accept. Planning is one of the modules; aggregation is often the lead.

Where these tools earn their keep: practices with high-net-worth clients, complex data, and a need to centralize the financial picture as the planning surface.

Where they stop being the right tool: practices where the planning is the work, not a side surface to aggregation. The tax engine in this category has historically been good at the basics and approximate at the advanced cases (AMT, IRMAA two-year lookback, state-specific quirks).

Hybrid mid-market tools

RightCapital and a handful of others occupy this space. They are honestly trying to be both: cash-flow-aware enough for retirement-stage planning, portfolio-aware enough for accumulators. The execution varies by tool and by year — every tool in this category has shipped real engine upgrades over the last five years.

Where they earn their keep: practices that span the spectrum and want a single tool that handles both ends acceptably.

Where they stop being the right tool: practices where one paradigm dominates and the tool's compromise is the wrong compromise for the work.

Newer entrants

There are a handful of tools (including ours) that were built in the last few years from a specific point of view about which paradigm should be at the center. Foundry's bet is that cash-flow-first, with a single calculation engine running tax / cash-flow / Monte Carlo as one computation, is the right shape for the next decade of planning practice. Other newer tools have placed their bets differently. The best advice I can give about evaluating any newer entrant is: test the engine, not the marketing. Run a real scenario through it. Watch how it handles the case where the answer depends on a specific tax interaction in a specific year.

Demo questions that surface differences

If you are sitting through demos and want to cut through the script, a few questions tend to be productive:

1. "Can you show me a Roth conversion in 2027 and walk me through what happens to IRMAA in 2029?" — This forces the tax engine, the projection horizon, and the cash-flow connection to all engage at once.

2. "Can we change the retirement year live, and watch the rest of the plan recompute?" — Tests engine speed and the integration of inputs to outputs.

3. "Show me where the AMT calculation lives in the tax engine, and how it changes when itemized deductions cross the SALT cap." — A specific tax-engine fidelity check.

4. "For a client with $X of qualified-business income, what's the marginal cost of the next dollar of W-2 wage versus the next dollar of distribution?" — Tests whether the tool actually computes interactions or hard-codes a heuristic.

5. "What does the import look like for a client we already have in [current tool]? How much manual cleanup will the first plan take?" — Real-world transition test.

6. "What does pricing look like at three advisors, ten advisors, and fifty advisors? What's tiered, and what's flat?" — Cuts through pricing complexity.

7. "Show me the cash-flow report a client takes home from a meeting. Can they read it without me?" — Client-facing readability check.

These are not gotcha questions. They are the questions that surface differences between tools that demo similarly.

What switching actually costs

If you are switching tools, plan for:

• Roughly two to four weeks of degraded throughput as the team learns the new platform
• Per-client setup time that is meaningfully higher than steady-state — call it 50–100% more for the first dozen clients
• A small number of clients whose plans don't import cleanly and have to be rebuilt
• A learning curve on the new tool's workflow shape, which is the part that takes longest to internalize

The transition cost is real. It is not a reason to stay on a tool that's structurally wrong for your practice. It is a reason to choose the next tool carefully enough that you don't make a second transition in two years.

What I'd do today

If I were choosing a planning tool today, with a working advisor's practice in front of me, the order of operations I'd run is:

1. Decide the paradigm. Cash-flow-first or portfolio-first. The paradigm dominates everything else.
2. Test the tax engine on the cases that actually matter — IRMAA bracketing, AMT, QBI, state-specific quirks.
3. Test the recompute speed by changing real inputs and watching real outputs.
4. Sit through the client-facing report and ask whether you'd hand it to a client and trust them to read it.
5. Run a real client through the import path.
6. Negotiate the pricing.

The paradigm decision dominates. If you skip it, you risk choosing a tool whose answer to every other question is "yes, but" — yes it does cash flow, but the engine is portfolio-first; yes it has a tax engine, but the engine is approximate at the cases that matter; yes it recomputes fast, but the recompute is on a portfolio model not the cash flow.

If your practice is shaped around cash-flow-first planning, we built Foundry Planning for this. If it's shaped differently, there are tools that fit better — and the framework above is the framework I'd use to find them.

What's next in this cluster

This pillar opens onto the tooling cluster. Future spokes will cover specific head-to-head comparisons (Foundry vs MoneyGuide, vs eMoney, vs RightCapital — written in the same honest-evaluation voice as this post), the unglamorous details of importing legacy plan data, and a workflow walkthrough of a shoulder-to-shoulder planning meeting.

In the cash-flow cluster, the pillar on cash-flow vs portfolio modeling is the deeper argument behind the paradigm decision above. In the tax cluster, the IRMAA spoke is the most concrete example of why the tax engine's fidelity matters.

If you'd like to see what cash-flow-first planning looks like in the room, we should talk. If you've read this far and disagree with anything in the framework, hello@foundryplanning.com — disagreement is more useful than agreement.

---

If there's a planning-tool question you'd like covered in a future spoke, the inbox is open. Honest comparisons require honest information; we'll cite primary sources where they exist and flag opinion where it's opinion.