Subcontractor Management Software Problems: The 7 That Cost General Contractors Real Money, and How to Avoid Them

Why does a certificate get scoped as a document with an expiry date?

Nearly every compliance project starts from the artefact rather than the obligation. The requirement is written as track certificates of insurance and chase renewals, so the developer models a certificate as a document with a policy number, a limit and an expiry date. That model is wrong in a way that only shows up when a claim is denied.

What actually governs is the prime contract. A hospital job flows down higher general liability limits, an umbrella layer, specific additional insured endorsement form numbers, waiver of subrogation and a notice of cancellation provision. A warehouse two counties over requires a fraction of that. Your requirements are not a company standard, they are a per contract matrix that changes with every owner, and the certificate itself is only evidence, not the requirement. The endorsement pages that actually prove additional insured status are the pages that most often never arrive.

The fix is to model the requirement set at buyout, per project, and evaluate coverages against it rather than tracking dates. An expiry alert tells you a document is stale. A requirement evaluation tells you the sub is uninsured for the risk your contract assigned them, which is the only fact that matters. Make a prospective developer draw the data model in the first meeting: subcontractor, master agreement, project commitment, requirement set, certificate, endorsement, waiver, pay application, payment. If a certificate appears as a document with a date and nothing evaluates it against a per project requirement set, the model will not survive its first owner audit.

What goes wrong migrating years of certificates and waivers out of email and SharePoint?

Every general contractor has the same archive: a shared inbox named for certificates, a folder tree organised by project then sub except on the older jobs where it is sub then project, and an Excel tracker with more columns than anyone can read. The instinct is to import all of it. That is where schedules slip.

Three problems are specific to this data. Sub identity is inconsistent, because the same legal entity appears as three vendor records with three spellings and one of them is a d/b/a. Documents are unstructured, so a scanned certificate faxed by a broker in 2019 will not parse to the same confidence as a clean file from last month. And historical requirement sets do not exist, since the contracts those certificates were issued against were never recorded as structured requirements, so there is nothing to evaluate old documents against even after you have imported them.

The fix is scope discipline. Only active subs matter for enforcement, so a contractor with several hundred subs verifies the current records rather than a decade of history, and everything older becomes an indexed archive you can search but do not evaluate. Resolve entity identity first, before any document import, because every later join depends on it. Expect a compliance coordinator to spend two to three weeks confirming low confidence matches, and put that time in the plan rather than discovering it.

Why does the ERP (Enterprise Resource Planning) write path break after launch?

Reading from your accounting system is easy. Writing a payment hold into it is the product, and it is where these projects fail quietly after go live.

The failure modes are specific. Sage 300 CRE typically connects through its ODBC layer, which behaves differently from a modern interface and is sensitive to version upgrades your controller schedules without reference to your compliance system. Viewpoint Vista and Foundation expose interfaces but the permissions to write are held by accounting, not by the compliance office, and an accounting staff change can quietly remove them. Payment runs happen on a fixed calendar, so a sync that fails on a Thursday night has consequences by Friday afternoon rather than next week.

There is also a governance failure that is not technical at all. A hard block that people cannot override gets worked around, usually by processing the payment outside the normal run. The design that survives is a block with an override that requires a named approver and a typed reason, every instance logged. After a claim, that override log is the first thing your carrier and your auditors ask for.

The fix is to treat the write path as a monitored production integration: alert when a sync fails rather than logging it, re test after every ERP upgrade, and hold the credentials with a named owner in accounting who knows what they are for. Ask any developer to describe a previous integration with your ERP by name before signing anything.

What happens when lower tier waivers and aggregate exposure are not covered?

Two exposures sit outside almost every first release and both are the kind that surface as a surprise on a specific job.

The first is the lower tier. Your drywall sub signs everything correctly and their board supplier, who has not been paid, can still lien your project. Almost no general contractor systematically collects lower tier waivers, because tracking them in a spreadsheet across sixty subs and their suppliers is not survivable by hand. The fix is structural rather than clerical: subs declare their suppliers at contract signing, and lower tier waivers become line items on every draw rather than a request made after a lien notice arrives.

The second is aggregate prequalification exposure. A sub prequalifies in January with a single project limit that made sense at the time. By August they hold six of your contracts because six project teams awarded independently and the prequal file is a PDF nobody joined to live commitment data. Meanwhile their experience modification rating drifted and nobody rechecked, because rechecking is an annual event.

The fix is to join prequalification data to contract records so aggregate committed value per sub across every active project is enforced at award time inside the buyout workflow, with alerts when a new commitment would breach the limit or when safety metrics cross your thresholds. Neither of these has to be in release one. Both belong in the roadmap with a date, because they are the exposures your risk manager will be asked about.

Should you build custom or configure what you already own?

Off the shelf is genuinely right for many general contractors. If you run fewer than about fifteen concurrent projects in one state, your insurance requirements barely vary by owner and your accounting is QuickBooks, then myCOI or TrustLayer for certificates plus Levelset on the projects that need waivers is the correct answer, and a custom build would be an expensive vanity project.

Before commissioning anything, use what you already have properly. Most contractors running Procore have not configured its compliance features or its prequalification module fully, and most running a certificate service have never given that service their actual per project requirement sets because nobody extracted them from the prime contracts. Doing that extraction is useful work whichever route you take, and occasionally it removes the reason for the project.

Build when the signals are concrete rather than aspirational. Compliance headcount scales linearly with revenue. The hold list is an emailed spreadsheet enforced by memory and a clerk covering a vacation. You have already absorbed one uninsured claim or one supplier lien that a payment block would have stopped. Owners are flowing down requirements your tools cannot model. Past roughly twenty five concurrent projects the link between compliance status and money movement stops being an administrative function and becomes the risk engine of the business, and none of the point tools is allowed to reach into your accounting system and stop a check.

How do hidden costs get into the quote?

The number of states you operate in is the first, because each adds statutory waiver forms and notice rules. A dozen states, including California, Texas, Florida and Georgia, mandate specific waiver language, and getting the form or the through date wrong can void the protection you thought you had. Ask for a price per state and how templates are versioned when a legislature amends the language.

The second is your ERP. Sage 300 CRE through ODBC is more integration effort than a modern interface, and the write path costs more than the read path. Get the system named in the contract along with the specific transactions.

The third is document parsing accuracy. Anyone who promises full automation on certificate and endorsement extraction is selling a claim you will absorb later. The credible design is machine extraction with confidence scoring and a human review queue that shrinks month over month, and the cost sits in the last stretch of accuracy, which is exactly where the lawsuits live. The fourth is security requirements flowing down from institutional owners, such as single sign on and audited hosting, which appear late in the process and are rarely in the original number.

What separates a build that works from one that fails here?

The build that works enforces. The one that fails reports. That is the whole distinction, and it is visible in the first design conversation.

Ask what happens at the moment a payment proposal is created in your accounting system. You want one continuously computed compliance state per sub per project covering insurance conforming to the project requirement set, waivers current, licence and tax documentation on file and prequalification unexpired, checked before release, with overrides recorded against a named approver. Ask how a deficiency letter is generated, because it should name the exact missing endorsement form numbers rather than saying the certificate is non compliant. Ask about lien law specifically: which states mandate statutory forms, and how the build versions a template when the language changes. A vague answer means you become their legal research department on your own budget.

On adoption, subs will use a portal when the portal is the only path to payment, and they already tolerate paying to use billing platforms for exactly that reason. A free portal that shows precisely what is blocking their check gets adopted faster than either, provided you keep email intake as a fallback and let the system file whatever still arrives that way.

Then settle ownership before kickoff. You should hold full assignment of the source code, your own cloud accounts and your data, so you can take the system in house or to another firm at any time. At Digital Heroes the client owns the code from the first commit, and any firm proposing to licence their platform back to you is a software vendor rather than a builder, which is a different deal with different economics.