Automated Underwriting Software: What to Test

Automated underwriting software should be judged by the jobs it takes off an analyst's desk, not by a vendor slogan. For a multifamily acquisition team, those jobs are narrow. Take in a flyer, offering memorandum, rent roll, and trailing-12 operating statement. Let people correct the extracted figures. Hold assumptions the team can change. Hand back a model someone else can open. A product that only produces a score, or that hides the workbook, has answered a different question.

Read how document intake, review, and Excel export work

Search results for automated underwriting software are mostly about consumer loans, mortgages, and bank credit decisions. That software can be useful to a lender. It is a poor template for a buyer who is screening a property. Loan engines often pull credit files and return an approve, refer, or deny. Acquisition work starts with messy property files and ends with a model a person still has to stand behind. The OCC's Commercial Real Estate Lending booklet says repayment of an income-producing property loan typically depends on the property's cash flow, and that unsupported analysis should be challenged.

What automated underwriting software is being asked to do

Write the job before you book a demo. If the job is "tell us whether to buy," no product should get that assignment. Software can prepare inputs. It cannot replace the investment decision, and it is not tax, accounting, or financial advice. Evaluations can be wrong. Someone on the team still checks them against the source documents.

A practical test has five jobs:

• Document intake. Can the team send the files they already have, without rebuilding them first?
• Extraction review. Can a person see classifications and unit mix and correct them?
• Assumption control. Can the team change cap rate, growth, financing, and renovations and run the model again?
• Editable output. Does the team receive a workbook it can keep, not only a view inside the vendor's app?
• Audit trail. Can a later reader see which file a figure came from, and who changed an assumption?

Keep neighboring jobs out of this test. A day-to-day walkthrough of rent rolls and T-12s is a workflow guide. A note on where scans and handwriting fail is a limits essay. A survey of commercial underwriting features across asset types is a different buyer's guide. This page stays on the evaluation itself.

Document intake: start with the files you already get

Ask for a trial on a real packet, not a cleaned sample. A one-page flyer is a fair starting point. It is not a full underwriting package. The better question is what happens when the OM, rent roll, and T-12 arrive later. The model should sharpen as those files are added, and the team should still be able to see which figures came from the thin packet.

Check the file types the product documents, not the phrase "any format." For an acquisition tool. Excel, CSV, and PDF are the formats that matter, including exports from common property-management systems. A scan that will not open on your own computer will not become a clean rent roll because a model touched it. Poor or truncated scans should be replaced with a clearer export.

Also test the path your team already uses. Some people upload inside an app. Others forward a broker email. Email can be a valid intake door. It is not, by itself, proof that a new sender gets the full product with no account. New senders may be asked to sign up, and email underwriting can be limited by plan. Confirm both before you treat inbox forwarding as the whole workflow.

Two intake questions are enough for a scorecard:

• Did the product accept the flyer alone, then accept the rent roll and T-12 without making the team reformat either file?
• Are the original files still available next to the model, so a reviewer can open the same PDF the extraction used?

Assumptions the team can see and change

Extraction is not underwriting. After the documents are in, the buyer should be able to change the inputs that actually move the deal. On a multifamily acquisition those usually include unit mix, expense categories, cap rate, growth, financing, and renovation scope. If those fields are locked, or if changing them requires a vendor analyst, the software is a report generator.

Ask where each assumption starts. A blank property input with documented defaults is easier to defend than a default buried in a formula. The team should be able to say which numbers came from the rent roll. Which came from the T-12, and which are the team's own view of the future. Market context, such as expense benchmarks or rent comps, can inform that view. It should be labeled as context, not dropped into the model as if it were a fact from the OM.

Run one deliberate change during the demo. Pick a single exit cap, or a single renovation line, and ask to see the model before and after. You are not scoring the return. You are scoring whether the change is visible, whether it can be reversed, and whether a colleague can tell what you did. If the only way to explain the change is "the AI updated it," stop there.

Editable outputs, not a trapped model

The output test is simple. Can an analyst open the result in Excel, or a compatible spreadsheet, and keep working after they leave the product? A portable workbook matters because investment committees, partners, and outside counsel do not all live in the same app. A view-only dashboard can be a fine working surface. It is not a substitute for a file the team can store with the deal.

Read the workbook before you praise it. Check that income, expenses, debt, and cash flow are laid out in cells a person can trace. Check that a changed assumption can be exported again, so the file on disk matches the file on screen. An export that goes stale the moment someone edits the web model will create two versions of the deal by Friday.

Sharing is a separate job from exporting. A team may want a view-only link, an editable link, a confidential link that hides selected assumptions. Or a broker room where an invited buyer gets a copy rather than the source model. Those controls are worth testing if you actually share deals. They do not prove the underwriting is right. A buyer who opens a shared room is a recipient of that deal, not automatically a customer of the software.

Auditability: show the path from file to figure

An audit trail is the ability to answer "where did this number come from?" without calling the vendor. For each deal, a reviewer should be able to open the source file, see the extracted line, and see any override a teammate made. Inbound email, if email is part of intake, belongs in that same packet. It should not be forwarded to people who were only given a share link.

The OCC booklet is a useful standard even though it is written for banks, not for sponsors. It says appropriate financial covenants on income-producing commercial real estate loans may include debt yield. Debt-service coverage, loan-to-value, loan-to-cost, and a borrower or guarantor minimum net worth or liquidity. It calls those the most common financial covenants. It also says debt-service coverage for a covenant may be defined differently from the ratio used in underwriting. If automated underwriting software prints DSCR or loan-to-value, ask it to show the income, expense, debt service, and value lines behind the ratio. A ratio with no definition is not an audit trail.

Provenance features do not erase extraction errors. They make the errors easier to find. Treat a missing source link as a failed test, even if the headline NOI looks familiar.

Human review is part of the product, not a footnote

Put a person between the extraction and the decision. The review is specific: classifications, unit mix, and the source documents, with extra care when the file is a scan or contains handwriting. A model can misread a concession, drop a unit type, or map an expense to the wrong category. Those mistakes survive into the returns if nobody looks.

Build the review into the scorecard instead of hoping the team will "be careful."

1. Open the rent roll and confirm unit counts, as-of date, and charges against the file, not against the summary card.
2. Open the T-12 and confirm that trailing income and expenses landed on the lines the team uses.
3. Mark every override. If the product has no place to record a correction, write it outside the tool and treat that as a gap.
4. Only then change assumptions and re-run. Do not tune cap rates on top of figures nobody has checked.
5. Re-export the workbook after the review so the file you circulate includes the corrections.

This is also the line between software and a services engagement. A product evaluation should be possible from the documented app: upload or forward, review, adjust, export. A separate implementation project, where a vendor builds custom workflows on your own process, is a different purchase. Do not let a demo of custom work stand in for the software test, or the reverse.

Request a demo and bring your own packet

A buyer's scorecard for the demo

Score the jobs, not the brand. Use one live deal the team already knows, ideally with at least one messy file. Give each job a pass, a gap, or a fail. A gap means the team can work around it. A fail means the team would have to trust a figure it cannot trace.

Do not add columns for speed, accuracy rate, or return on investment unless the vendor will show the test method on your own files. A timed demo on a friendly packet is not a benchmark. Public pricing should match what the vendor will actually put in writing. If the public line is "call for pricing," leave the cell blank rather than inventing a seat price or a deal allowance.

How Slung maps to those jobs

Slung is one option a multifamily team can hold up to the scorecard. It is an underwriting product for investors and brokers, paired with a separate, scoped service for teams that want custom workflows built on their own process. The product path and the service path are different purchases. This section describes the product path only, using what the company documents. It is not a claim that this automated underwriting software outperforms any other tool.

On intake, a user can upload Excel, CSV, or PDF in the app. Including files from major property-management systems, or forward a flyer, OM, rent roll, or T-12 to sam\@slung.ai. A flyer can start the file. The OM, rent roll, and T-12 are what refine it. Email is an entry point. New senders may be guided to create an account, and email underwriting can depend on the plan. Plans are named Free Analyst, Principal monthly, and Principal annual, with a trial only when one is offered. Public pricing is "call for pricing." There is no published seat price or deal cap to quote.

On review, the documented workflow is to inspect the extraction, edit line items and unit mix, and only then rely on the numbers. Scans and handwriting need that check. The property view lets the team adjust assumptions such as cap rates, growth, financing, and renovations, and run the analysis again. Expense benchmarks and rent comps are presented as market context tied to the deal. They are inputs to review, not a substitute for the source documents.

On output, the team can download an editable Excel workbook and keep working offline. After assumption changes, the current file is a new export, not the first download. Sharing can be view-only or editable, with an option to hide selected assumptions on paid confidential links, and with the document vault included only when the sender chooses. A broker DataRoom, where offered on a paid plan, gives an invited buyer a separate copy. It does not make that buyer a software customer, and it does not open the broker's source model to them.

Slung does not claim a finished SOC 2 examination. The security page describes a SOC 2-aligned program that is still in progress, monitored with Vanta, and says the examination is not complete. Ask for that page, and for the current data-use terms, rather than accepting a certification badge. None of this output is a recommendation to buy or pass on a property.

If you want the product path, create an account and run one of your own packets through the scorecard. If you want custom workflow work instead, that conversation starts on the Enterprise page, scoped to your team. For how source-to-model review fits a decision, see the source-to-decision investment analysis guide. For the file-by-file check behind a model, use the real estate document review guide and the rent roll fields and dates primer.

FAQ: questions buyers ask before they choose

What should automated underwriting software do for an acquisition team?

It should take in the deal files you already receive, let a person correct the extraction, expose the assumptions, and return a workbook the team can keep. It should not be asked to approve the deal. The decision stays with the people who will own the result.

How is this different from loan underwriting software?

Loan tools often read an application and a credit file, then support an approve, refer, or deny decision. Acquisition tools start from property documents such as a rent roll and a T-12, and they prepare a model. Ratios such as DSCR can appear in both, but the source files and the decision are not the same.

Which documents are enough for a fair test?

Start with a flyer if that is all you have, then add the OM, rent roll, and T-12 from the same deal. Ask the vendor which formats are documented. Excel, CSV, and PDF are the formats to confirm. Treat a promise of every format, or of a guaranteed turnaround, as unproven until you see it on your file.

What counts as an audit trail?

You can open the source document behind a rent, an expense, or a ratio, and you can see any override. A debt-service coverage figure should show the income and debt-service lines used to calculate it. Those lines may not match a lender's covenant definition, which is a reason to label them.

Where does human review belong?

Before anyone relies on the model. Check classifications, unit mix, and the source files, especially scans and handwriting. Then change assumptions, run the model again, and export a fresh workbook. Software output can be inaccurate, and it is not professional investment advice.