How to Evaluate LIHTC Feasibility Software Using One Real Deal

1. Ask where an assumption came from

Select a rent limit, utility allowance, fee, or scoring assumption. Ask to see the source, applicable geography, effective period, and any qualification attached to it.

A recognizable agency name is a starting point. The reviewer needs enough detail to reach the actual supporting document and determine whether it applies to the project.

For example, HUD maintains separate MTSP income-limit materials and QCT/DDA designation materials. These inputs answer different questions. A system should make those distinctions understandable instead of presenting every external input as equally current and universally applicable.

2. Change a meaningful input and follow the consequences

Change the unit mix, an operating expense, or the construction budget. Observe which outputs move: income, operating cash flow, debt capacity, financing gap, and any affected program tests.

Ask which values are recalculated and which require a manual update. A clear manual step can be manageable; an undisclosed one can leave an old assumption inside a new scenario.

For your evaluation record, save the starting values, the changed input, and the expected direction of the result. Investigate differences before treating either the spreadsheet or the software as correct.

3. Separate eligibility, scoring, and financial feasibility

These are different tests. A project can balance financially while missing an eligibility requirement. It can satisfy threshold requirements while remaining uncompetitive. It can score well while carrying an unresolved funding gap.

Ask the vendor to show each conclusion separately and explain the evidence behind it. Identify how the system handles rules that need judgment, documentation, or an agency determination.

State coverage should also be specific. Ask which states and program types have detailed support, which features are available in each, and where the user must supply or verify assumptions. A coverage count alone does not establish that every workflow has the same depth.

4. Test financing timing as well as totals

Enter a source that becomes available later than the cost it is intended to support. Check whether the workflow distinguishes a long-term financing plan from cash needed during development and construction.

Ask how conditional sources, deferred fees, bridge financing, and financing costs are represented. The goal is to understand the model’s scope. A feasibility tool does not need to replace every specialist model, but your team should know where another analysis is required.

5. Reopen a saved scenario

Save a scenario, leave it, and reopen it. Compare the key inputs and outputs. Then ask how updated source data or calculation changes affect the saved result.

There are legitimate choices here: preserve the original assumptions, offer a controlled refresh, or show both. What matters is that the reviewer can tell what changed and reconstruct the decision made at the time.

Also ask how a colleague identifies the version approved for an investment meeting. Naming conventions, review notes, and clear ownership can matter as much as the speed of the initial calculation.

6. Inspect the export your team will actually use

Export the model or a supported application workbook during the demonstration. Open it and inspect several important values, labels, and assumptions. Confirm which outputs are editable and how the export handles fields the software cannot populate.

If a platform supports an agency application, verify the exact template and version. Demonstrating one supported workbook does not establish support for every state’s application.

A useful acceptance test is simple: a colleague who did not attend the demo should be able to understand what the exported result represents and where its limitations are.

7. Evaluate the work around the calculation

Ask who updates reference data, how corrections are communicated, what onboarding includes, and what happens when the team finds a discrepancy. Review access controls, data export options, support arrangements, and commercial terms before selecting a system.

Use a small scorecard: demonstrated, partially demonstrated, or not demonstrated. Add evidence and unresolved questions instead of relying on a single overall rating.

Bring your own acceptance criteria

Choose three outcomes before the demo. They might be reproducing a reviewed base case, comparing two financing scenarios, and producing an export your team can inspect. Use those same outcomes across the alternatives you evaluate.

For EZFeasi’s current product scope, review Feasibility Software and Site Feasibility. Book a demo and bring a site, an existing model, and the questions you want the walkthrough to answer.