Subcontractor Prequalification Software: How Do You Stop a Sub You Already Approved From Failing?

Why prequalification is a control, not a filing exercise

A drywall sub you approved fourteen months ago walks off a $9M package in month seven. The reason turns out to be boring. They took three large jobs from other general contractors in the spring, their backlog roughly tripled against a working capital position that had not moved, and they ran out of cash to make payroll on all four sites at once. Your prequalification file on them is a PDF of a compiled financial statement dated the previous December, a certificate of insurance, and an experience modification rate somebody typed into a spreadsheet.

Nothing in that file was wrong. It was simply answering a question from a different year. Meanwhile the completion cost, the schedule hit, the claims from the trades stacked behind them and the fee you no longer make on the job add up to a number that dwarfs anything you would ever spend on software. That asymmetry is the entire argument for taking prequalification seriously as a system.

Most contractors run this on a shared mailbox, an annual questionnaire in Word, a folder of PDFs, and one estimator or risk manager who knows in their gut which subs are shaky. The gut is often good. It is also unwritten, unauditable, and it leaves the company when that person does. And the gut does not scale to a bid list of 60 invitations across eleven trades on a job the chief estimator has not personally worked.

Problem 1: the financial data arrives once a year and is keyed in by hand

Subcontractor financial packages come as PDFs, and they come in every possible shape: an audited statement from a real CPA firm, a review, a compilation with a disclaimer that says nobody verified anything, a QuickBooks export, and occasionally a scan of a printout. Somebody in your office pulls current assets, current liabilities, revenue, net income, the bonding letter, and the work in progress schedule, and types them into a spreadsheet. That takes twenty to forty minutes per sub when it goes well, so a contractor with 400 approved subs is spending real months of staff time producing numbers that go stale immediately.

This is the one place where document extraction genuinely earns its cost. A model reads the statement, pulls the line items, records the level of assurance because a compilation and an audit are not the same evidence, and flags what it could not read for a human to finish. In our builds the useful measure is not accuracy on a demo, it is how few fields a reviewer touches after the first month of corrections. Extraction is not the interesting part of the system, but it is the part that decides whether anyone keeps the data current.

Problem 2: the scoring model is someone else's risk appetite

TradeTapp and COMPASS by Bespoke Metrics both compute financial capacity scores, and the underlying analysis is competent. The catch is that the weighting represents a general view of contractor risk, and your view is not general. A curtain wall sub with heavy material buyout carries different working capital pressure than a labour heavy framing sub. If you self perform concrete, your concrete subs are a smaller and more scrutinised group. If you build data centres, an electrical sub's ability to secure gear is worth more in the model than its EMR.

ISNetworld, Avetta and Highwire are also frequently mistaken for prequalification, and they are not answering this question. They are compliance and safety qualification networks. They will tell you whether a sub has submitted the right paperwork and whether their safety record clears a threshold. That is genuinely useful and it is a different question from whether this company has the balance sheet to carry your $12M package through a six month cash gap.

What a build gives you is a model you own. Working capital, backlog to capacity ratio, current ratio, profit trend, bonding capacity headroom, safety history, claims and lien history, and trade specific factors, each with a weight your risk committee argued about and can change without a vendor ticket. When a package fails, you can look at what the model said and adjust it, which is the only way scoring gets better over time.

Problem 3: the score does not stop anybody from bidding

This is the failure that matters most and the one nobody talks about. In the majority of contractors we have worked with, prequalification produces a report. Bid lists are built in a different system, or in an estimator's head, or from the list of subs who called that week. The single project limit and aggregate limit exist as numbers on a page rather than as a gate.

The control has to sit at the moment of invitation. When an estimator adds a sub to a bid list for a $14M mechanical package, the system checks the sub's single job limit, checks their current aggregate exposure across every one of your live jobs, checks whether their insurance and licensing are current on the day, and either allows the invitation, allows it with a flag and a named approver, or blocks it. That approval, with the approver's name and reason, becomes the record. Without that gate you have bought analytics. With it you have bought a control.

Problem 4: exposure is tracked per job, never in aggregate

Individual project managers know what their sub is carrying on their job. Nobody knows what that sub is carrying across your seven active jobs, three operating companies and two joint ventures, and the sub is unlikely to volunteer what they are carrying for your competitors. Aggregate exposure is the number that kills you, and it is the number that lives nowhere.

A build maintains a live position per sub: awarded value, billed to date, retention held, and remaining exposure across all entities, plus their self declared backlog elsewhere and their bonding capacity headroom. Underwriters conventionally look at bonding capacity as a multiple of working capital, and your surety will tell you the multiples they use, but the useful discipline is simply having the two numbers side by side and a trigger when one crosses the other. When a sub's exposure with you passes a threshold, the system asks for updated financials rather than waiting for the annual cycle.

Problem 5: nothing rescreens between annual renewals

The default failure in this whole category is time. Approval is an event and risk is continuous. Between the December statement and the following December, a sub can lose their largest customer, have a judgment entered, let a licence lapse, get their EMR restated, or double their backlog. A build that only reprocesses annually is a slower version of the spreadsheet.

What continuous monitoring means in practice: licence status checks against state boards where the data is available, lien and judgment monitoring, insurance expiry from certificate data, EMR updates at each policy year, and self reported backlog updates that you make a condition of remaining on the bid list. Then triggers: any material change reopens the file and, depending on severity, suspends the sub from new invitations until a human reviews it. That last part is the difference between monitoring and alert noise.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, the honest shape here is as follows. A first release covering financial intake and extraction, your scoring model, sub profiles, and single plus aggregate limits enforced at the bid invitation runs $60,000 to $130,000 and ships in 10 to 16 weeks. A full platform adding continuous monitoring and watchlists, safety and insurance data, buyout and subcontract integration, joint venture and multi entity exposure, and a sub facing portal runs $150,000 to $350,000 over 6 to 12 months.

What drives the number up: multiple operating companies with different risk appetites, because that means multiple models and consolidated exposure. Integration with your ERP (Enterprise Resource Planning) for live commitment and billing data, and Viewpoint Vista, CMiC and Sage 300 CRE are each their own project. A subcontractor facing portal, because you are then supporting hundreds of external users with password resets and document uploads. And feeds from ISNetworld or Avetta if you want to keep those subscriptions and consume their safety data rather than duplicate it.

What keeps it down: start with your top two trades by risk exposure and your live bid list. You will learn more from four weeks of real invitations passing through a gate than from a year of designing scorecards.

Build versus buy, and when buying is right

Buy if you are a single operating company under roughly $150M in annual volume with a conventional trade base and no self perform. TradeTapp is a reasonable answer, particularly if you already live in Autodesk Construction Cloud, and COMPASS does a serious job on financial analysis. Keep ISNetworld or Avetta if your clients require them, and do not attempt to rebuild safety compliance networks. That is not the part that is broken.

Build when two or more of these are true. You run multiple operating companies or joint ventures and aggregate exposure is invisible. Your trade mix is unusual enough that a general scoring model misprices your actual risk. You need the score to gate invitations inside your own estimating process rather than sit in a separate portal. You are an owner or a private equity backed rollup imposing one standard across acquired contractors. Or a package default has already cost you a fee, in which case you already know the arithmetic.

How to choose a developer for prequalification software

Ask them to model the exposure calculation on a whiteboard. The right answer covers awarded versus billed versus remaining, retention, change orders in progress, exposure across entities, and self reported outside backlog. Someone who draws a sub table with a status field has built a supplier directory.

Ask how the scoring model is changed. If adjusting a weight requires a developer, the model will freeze the day the project ends and your risk committee will go back to spreadsheets within a year.

Ask about the audit trail on exclusion. Removing a subcontractor from a bid list has commercial and sometimes legal consequences, so the system needs to record what data drove the decision, who approved the override, and when. Ask them to show you what that record looks like when printed.

Ask who owns the code, and get it in writing before kickoff. You should hold the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk from anyone who treats that as negotiable.