Compliance

Contractor management for complex org hierarchies

Six real contractor structures, what cascades on its own, what quietly does not, and the specific failure mode for each. Grounded in FAR, 13 CFR, and 29 CFR.

On this page
  1. What counts as a complex organizational hierarchy in construction?
  2. Which compliance obligations cascade automatically, and which do not?
  3. Where does compliance break in each organizational structure?
  4. How do compliance obligations work in a multi-entity holding company?
  5. Whose compliance record and whose insurance apply in a joint venture?
  6. How does a requirement reach a third-tier subcontractor you have no contract with?
  7. How do you handle the same subcontractor on multiple projects with different requirements?
  8. What does a system have to model to handle this correctly?
  9. Why does a spreadsheet per project fail exactly here?
  10. What this page does not cover
  11. Frequently asked questions
  12. Your org chart is not a vendor list.

Which compliance obligations cascade through a multi-entity, joint venture, or multi-tier structure, which ones quietly do not, and what a system has to model to keep them straight.

Contractor management software handles complex organizational hierarchies when it models the legal entity, the project, and the contract as three separate objects, attaches compliance requirements to the contract rather than to the vendor record, and tracks compliance state per project rather than per vendor. Software built on one flat vendor list cannot represent these structures, and it fails in predictable places.

This page covers the six structures that actually show up on construction projects: multi-entity holding companies where the contracting entity is not the operating entity, joint ventures, the SBA mentor-protege joint venture, multi-tier subcontracting below the first tier, the same subcontractor working several projects at different requirements, and regional divisions running their own standards. Teaming agreements get a row too, because they cause a specific and common mistake. For each one, what cascades on its own, what does not, and the exact way it breaks.

What counts as a complex organizational hierarchy in construction?

A complex organizational hierarchy is any structure where the party that signs the contract is not the same party that performs the work, holds the insurance, or carries the compliance record. That gap is the entire problem, and everything else on this page is a variation of it.

Most compliance tracking assumes a flat world: one company, one project, one set of requirements, one folder. Real construction organizations are not shaped that way, and the bigger the contractor the less true it gets. The Census Bureau’s Statistics of U.S. Businesses for 2022 counts 782,487 construction firms operating 800,651 establishments nationally. That overall ratio looks almost flat, but it is dominated by the small end: firms with fewer than five employees account for 524,170 of those firms across 524,204 establishments, essentially one location each. At the other end of the same table, the 1,295 construction firms with 500 or more employees operate 12,256 establishments between them, an average of roughly nine and a half locations per firm.

That is the shape of the problem. The contractors most likely to hold federal work, carry bonding capacity, and manage large subcontractor counts are the same contractors least likely to be a single box on an org chart. They are the ones whose compliance systems were designed for the single box.

Which compliance obligations cascade automatically, and which do not?

Almost none cascade automatically. A compliance obligation moves from one tier to the next only when a human writes it into the next contract down, and the only obligations that travel further than one tier are the handful where a regulation explicitly instructs each tier to keep passing them along.

This is worth stating plainly because the language people use gets it backwards. Contractors talk about requirements that “flow down” as though gravity does the work. What the regulations actually create is a recursive instruction: insert this clause, and insert a clause requiring the next party to insert this clause. Davis-Bacon is the clearest example of the pattern, and of the liability that attaches when the chain breaks.

“The contractor or subcontractor must insert in any subcontracts the clauses contained in paragraphs (a)(1) through (11) of this section, along with the applicable wage determination(s) and such other clauses or contract modifications as the [write in the name of the Federal agency] may by appropriate instructions require, and a clause requiring the subcontractors to include these clauses and wage determination(s) in any lower tier subcontracts. The prime contractor is responsible for the compliance by any subcontractor or lower tier subcontractor with all the contract clauses in this section.”

29 CFR 5.5(a)(6)

Read those two sentences together and the asymmetry is obvious. The obligation to transmit the clause is recursive and depends on every tier doing its job. The liability is not recursive at all. It lands on the prime regardless. The same paragraph goes on to say that in the event of violations, the prime contractor and any responsible subcontractors “will be liable for any unpaid wages and monetary relief, including interest from the date of the underpayment or loss, due to any workers of lower-tier subcontractors, and may be subject to debarment, as appropriate.”

The consequences are not theoretical. The Department of Labor’s Wage and Hour Division publishes enforcement data by industry, and for fiscal year 2025 its construction row records 1,802 compliance actions, $43,420,356 in back wages recovered, 18,340 employees receiving those wages, and $4,819,567 in civil money penalties assessed.

So the honest general rule is this: contractual obligations cascade only as far as the paper you actually wrote, and financial and regulatory liability cascades further than that. The gap between those two distances is where firms get hurt.

Where does compliance break in each organizational structure?

Each structure has one characteristic failure mode, and in every case it comes from an obligation that was assumed to travel and did not. The matrix below is the short version of the rest of this page.

Structure What cascades on its own What does not cascade The specific failure mode
Multi-entity holding company (contracting entity is not the operating entity) Nothing between sister entities. Each is a separate contracting party. Insurance, licenses, safety record, and past performance do not transfer between affiliates because a parent owns both. A poor record can still be held against you under FAR 9.104-3(c)(1). The contracting entity signs, a sister operating entity performs, and the certificate of insurance names the operating entity. The certificate is genuine and the wrong party is on it. Nobody notices until a claim or an audit asks who was actually obligated.
Joint venture (two contractors, one pursuit) The joint venture’s own contractual obligations bind the joint venture. Neither partner’s insurance, licenses, or past performance automatically become the joint venture’s. The joint venture is a new party with no record of its own. Everyone assumes the larger partner’s coverage and record carry the joint venture. Certificates name a partner rather than the joint venture, and the entity actually holding the contract is uninsured on paper.
SBA mentor-protege joint venture Past performance and experience of both partners are considered together (13 CFR 125.8(e), FAR 9.104-3(c)(2)). The mentor’s size and record do not make the protege compliant. Workshare does not track itself, and records do not stay wherever is convenient. Workshare is measured at the joint venture level while the mentor subcontracts to its own affiliates. Under 13 CFR 125.8(c)(3) all work done by the mentor and any of its affiliates at any subcontracting tier counts against the mentor, so the protege’s required 40% is breached on paper before anyone runs the numbers.
Multi-tier subcontracting (second tier and below) Only clauses a regulation requires each tier to insert, and only if each tier actually inserts them. Nothing reaches a third-tier subcontractor through privity. You have no contract with them and no direct instruction to give. Tier one inserts the clause, tier two does not, tier three underpays its workers. Under 29 CFR 5.5(a)(6) the prime is still responsible for that compliance and liable for those wages.
Same subcontractor, multiple projects, different requirements Nothing. Each project’s requirements come from its own prime contract. An approved certificate on one project does not satisfy another project’s higher limits, different endorsements, or additional insured wording. The vendor record reads “compliant” because it was checked once against one project. The subcontractor works the second project underinsured relative to that contract, and the vendor-level green status is what hides it.
Regional divisions with their own standards Corporate minimum requirements, if the divisions actually apply them. A division’s stricter local requirement does not appear on the corporate vendor record, and a corporate approval does not encode which division cleared it. A subcontractor cleared at corporate minimums gets put to work in a region that requires more. Nobody re-checks, because the vendor already reads as approved at the company level.
Teaming agreement (before award) Nothing. A teaming agreement is an agreement to enter a contract later. It creates no privity with the eventual subcontractor and flows down no contract clauses, because there is no subcontract yet. The team member is treated as onboarded from the pursuit stage. Insurance, licenses, and clause acceptance are never collected, and the gap surfaces after work has already started.

How do compliance obligations work in a multi-entity holding company?

They do not travel between sister entities. Each legal entity in a holding company structure is its own contracting party with its own registration, its own insurance policies, its own licenses, and its own compliance record, and a shared parent does not merge any of them.

The federal system is built around that separation. FAR 4.1102(a) requires offerors and quoters to be registered in the System for Award Management at the time an offer is submitted, and FAR 4.1102(c) directs contracting officers to use the legal business name and physical address from the contractor’s SAM registration for the unique entity identifier provided. Registration attaches to a specific legal entity, not to a family of companies. If Holdings signs and Construction Services performs, those are two registrations, two identifiers, and two sets of representations and certifications.

The separation is not symmetrical, and this is the part that catches people. Good standing does not transfer, but a poor record can. FAR 9.104-3(c)(1) puts it directly:

“Affiliated concerns (see ‘Concern’ in 19.001 and ‘Small business concern’ in 2.101) are normally considered separate entities in determining whether the concern that is to perform the contract meets the applicable standards for responsibility. However, the contracting officer shall consider the affiliate’s past performance and integrity when they may adversely affect the prospective contractor’s responsibility.”

FAR 9.104-3(c)(1)

So a sister company’s problems can follow you into a responsibility determination even though its insurance certificate cannot follow you into a project file. The benefits stop at the entity boundary. The liabilities are more willing to cross it.

The practical consequence is that “which entity” has to be a tracked field on every compliance document, not something reconstructed later from a letterhead. Census data suggests how often this comes up: as noted above, the 1,295 largest construction firms by employment operate 12,256 establishments between them. Establishments are not the same thing as legal entities, but a firm that has grown to nine or ten locations has almost always grown a legal structure to match, through acquisition, regional incorporation, or the separate entities that set-aside eligibility requires.

Whose compliance record and whose insurance apply in a joint venture?

The joint venture’s own record and insurance apply first, and where the joint venture has none, both partners’ records are considered individually. What does not happen is the larger partner’s coverage silently protecting the joint venture, which is the assumption that causes most joint venture compliance failures.

On past performance the rule is explicit. FAR 9.104-3(c)(2) directs that for a prospective contractor that is a joint venture, the contracting officer shall consider the past performance of the joint venture, and if the joint venture does not demonstrate past performance for award, the contracting officer shall consider the past performance of each party to the joint venture. For SBA joint ventures, 13 CFR 125.8(e) goes further and requires the procuring activity to consider work done and qualifications held individually by each partner as well as any work done by the joint venture itself.

Insurance follows the opposite logic, and that is the trap. Past performance aggregates upward from the partners. Insurance does not. The joint venture is a distinct legal party, and a certificate naming one partner does not name it. If the joint venture holds the prime contract, the joint venture is the party with the contractual insurance obligation.

This is a mainstream construction structure, not an edge case. SBA publishes its active mentor-protege agreement list, and the file dated July 22, 2026 contains 1,967 active agreements. 415 of them, about 21%, sit under a construction NAICS code. Commercial and institutional building construction, NAICS 236220, is the single most common code in the entire program with 256 agreements, more than any professional services, engineering, or information technology code on the list.

The mentor-protege joint venture adds obligations that have nothing to do with insurance and everything to do with document control, and they are the ones firms miss:

  • Records live in a specific office. 13 CFR 125.8(b)(2)(ix) requires the joint venture agreement to designate that accounting and other administrative records relating to the joint venture be kept in the office of the small business managing venturer, unless SBA’s District Director approves keeping them elsewhere on written request. 13 CFR 125.8(b)(2)(x) requires the final original records to be retained by the small business managing venturer after contract completion.
  • Two reports are due on a clock. Annual performance-of-work statements go to SBA and the contracting officer no later than 45 days after each operating year of the joint venture, and the project-end statement no later than 90 days after contract completion, per 13 CFR 125.8(b)(2)(xi) and (xii).
  • Workshare counts through the org chart, not the contract. The protege must perform at least 40% of the work performed by the joint venture under 13 CFR 125.8(c)(1). Under 13 CFR 125.8(c)(3), in determining the amount of work done by a mentor, all work done by the mentor and any of its affiliates at any subcontracting tier will be counted.

That last one is the single hardest thing on this page to track and the most expensive to get wrong. It means the workshare calculation depends on knowing who the mentor’s affiliates are and where they appear anywhere in the subcontract tree, including tiers you did not award. And under 13 CFR 125.8(i), failure to perform in accordance with the joint venture agreement or the performance of work requirements is listed as a ground the Government may consider for suspension or debarment.

How does a requirement reach a third-tier subcontractor you have no contract with?

Only by being written into every contract between you and them, which means you are depending on parties you did not select to do paperwork you cannot see. There is no mechanism by which a requirement reaches a third-tier subcontractor directly, which is why the regulations that care about lower tiers assign the liability upward instead.

The two rules that matter here work differently and both bite. The first is the recursive-insertion rule already quoted: 29 CFR 5.5(a)(6) requires each contractor to insert the clauses and a clause requiring the next tier to do the same, and makes the prime responsible for compliance by any subcontractor or lower tier subcontractor. Your exposure does not stop at the tier where your paperwork stops.

The second is quieter and catches small business primes specifically. Under 13 CFR 125.6(a)(3), on a contract for general construction a small business prime may not pay more than 85% of the amount paid by the government to firms that are not similarly situated, and under 13 CFR 125.6(a)(4) the limit is 75% for special trade contractors. Cost of materials is excluded from both calculations. The provision that makes this an org-chart problem rather than an accounting problem is the sentence attached to each threshold: any work that a similarly situated subcontractor further subcontracts counts toward the amount that cannot be exceeded.

So a compliant-looking first-tier award to a similarly situated small business can put you over the limit based on what that subcontractor does two tiers down, with parties you never approved. Getting this right requires knowing the size and status of firms you have no contract with, and knowing what they were paid.

The aggregate enforcement picture gives a sense of scale. Summing the Wage and Hour Division’s published construction row across fiscal years 2013 through 2025 gives 36,472 compliance actions, $525,236,898 in back wages recovered, and 313,998 construction employees receiving them. That is a thirteen-year total we calculated from the agency’s own published annual figures, not a number DOL states as a single total.

How do you handle the same subcontractor on multiple projects with different requirements?

You stop storing compliance on the subcontractor and start storing it on the pairing of subcontractor and project. The same firm can be fully compliant on one job and deficient on another at the same moment, because the requirement comes from each project’s prime contract, not from the vendor.

This is the failure mode that a vendor-centric system is structurally incapable of representing. If your data model has one compliance status field per subcontractor, then two projects with different requirements must share one answer, and whichever project was checked last determines what the record says. The record is not corrupt. It is answering a question nobody should have asked.

The obligation itself is per-contract and explicitly the prime’s to carry. FAR 52.228-5(b) requires the contractor to insert the substance of the clause in subcontracts under the contract that require work on a Government installation, to require subcontractors to provide and maintain the insurance required in the Schedule or elsewhere in the contract, and to maintain a copy of all subcontractors’ proofs of required insurance and make copies available to the contracting officer on request. “The Schedule or elsewhere in the contract” is the operative phrase. The requirement is defined by that contract. A different contract defines a different requirement, and the same certificate may satisfy one and not the other.

Many-to-many relationships between organizations are the norm rather than the exception. In the same SBA active agreement file dated July 22, 2026, 315 mentors hold more than one active mentor-protege agreement and 100 proteges hold more than one. Any system that assumes one relationship per company pair is already describing something other than the industry it serves.

The practical rule: a subcontractor’s compliance state is a property of a project, not of the company. Approvals should be expressed as “approved for this project under this contract,” with an expiry, and never as a company-level badge.

What does a system have to model to handle this correctly?

Three separate objects, related rather than merged: the legal entity, the project, and the contract. Requirements attach to the contract. Compliance state attaches to the pairing of entity and project. Documents attach to the entity but are evaluated per contract.

That sounds abstract until you check it against the failure modes above, at which point it becomes a specification:

  • Legal entity as a first-class object, with relationships between entities. Parent, subsidiary, affiliate, and joint venture partner have to be representable and distinguishable. Without this, the holding company failure mode is undetectable, because there is nowhere to record that the signing party and the performing party differ.
  • Joint venture as its own entity, not a note on a partner’s record. It needs its own certificates, its own record, and links to its partners that are relationships rather than a merge.
  • Requirements attached to the contract, not the vendor. This is the load-bearing one. The moment requirements live on the vendor, the multi-project failure mode is guaranteed, because there is one place to store an answer to a question that has several correct answers.
  • Compliance state per entity-project pair, with its own expiry. The same subcontractor shows green on one project and red on another simultaneously, and neither is an error.
  • Subcontract tier as a modeled field, with visibility below tier one. You cannot track what you cannot represent. If the schema stops at the subcontractors you awarded, the Davis-Bacon and limitations-on-subcontracting exposures are invisible by construction.
  • Division or region as an attribute that can carry its own stricter requirement. Corporate minimums are a floor, and a floor is only useful if the system knows which regional ceiling also applies.
  • Documents indexed to the entity, evaluated against the contract. One certificate can satisfy three projects and fail a fourth. Storing the evaluation with the document rather than with the pairing loses that.

Nothing here is exotic. It is ordinary relational modeling. The reason it matters is that the common alternatives collapse these distinctions by design.

Why does a spreadsheet per project fail exactly here?

A spreadsheet per project gets each project right and loses every relationship between projects, which is precisely the information a complex hierarchy consists of. The per-project structure is not a shortcut that happens to be imperfect. It is a data model that has deleted the joins.

Three specific things break, and they break in the same order every time.

First, cross-project questions become manual. “Which of our subcontractors are working more than one job at different insurance limits” has no query. It has a person, a week, and a merged file. The answer is stale before it is finished.

Second, entity structure has nowhere to live. A spreadsheet column holding a company name cannot distinguish the contracting entity from the operating entity, and it cannot express that two rows are affiliates. So the holding-company mismatch and the joint venture certificate problem are both invisible, not because anyone was careless but because there is no field in which they could have been visible.

Third, nothing exists below tier one. Project sheets list the subcontractors you awarded. Your subcontractor’s subcontractors are not on it, and the obligations that reach them are the ones with the largest liability attached.

Project-management platforms with document storage solve the first problem partially and the second and third not at all. They give you one place for the files and usually a real vendor directory, which is a genuine improvement over scattered sheets. But their vendor record is typically one row per company, which reintroduces the multi-project failure mode, and their document storage is organized by project folder, which means a certificate’s compliance is judged once rather than evaluated against each contract that relies on it.

A dedicated contract and compliance hub is defined by making the opposite trade: entity, project, and contract stay separate, requirements live on the contract, and compliance is computed per pairing instead of stored per vendor. That is the whole architectural difference, and every failure mode in the matrix above traces back to it. For the mechanics of keeping that state current across a subcontractor base rather than the structural question this page covers, see subcontractor compliance automation→.

Our co-founder ran a large federal general contracting firm for 15 years, about 100,000 documents a year.

What this page does not cover

This page is about organizational structure and how obligations move through it. Several adjacent things are deliberately out of scope, and a few genuinely require someone other than a software vendor.

Not covered here: how to prequalify a subcontractor, how to read a certificate of insurance or verify an endorsement, state licensing requirements, bonding capacity, and the mechanics of certified payroll review. Those are separate subjects with their own rules.

Where you need a lawyer, not a system. Whether a particular entity structure creates affiliation under 13 CFR 121.103, whether a specific joint venture agreement satisfies 13 CFR 125.8(b), and whether a given teaming arrangement creates obligations before award are legal questions with real consequences, including the suspension and debarment grounds listed at 13 CFR 125.8(i). Software can tell you what your structure looks like and what your documents say. It cannot tell you whether your structure is lawful.

Where you need your contracting officer. Agency-specific insurance overlays, whether a particular lower-tier arrangement requires consent, and how a specific solicitation treats joint venture past performance are all answered by the contract and the contracting officer, not by a general rule.

What no system can do. No platform can see a subcontract it was never given. Visibility below tier one depends on the tier above actually reporting who they hired, and that is a contractual and relationship problem before it is a software problem. A system can make the gap visible and demand the data. It cannot manufacture information nobody sent. Any vendor claiming full lower-tier visibility without a reporting obligation in the subcontract is describing something they cannot deliver.

On the numbers here. The Census and Department of Labor figures on this page are current published federal data as of July 29, 2026, and the arithmetic that combines them is identified as ours where it appears. Enforcement figures and program counts change. Verify anything you plan to rely on against the source, which is linked below.

Frequently asked questions

What contractor management software handles complex organizational hierarchies?

Software handles complex hierarchies when it models the legal entity, the project, and the contract as three separate objects, attaches requirements to the contract rather than to the vendor, and stores compliance state per project instead of per vendor. A useful test: ask whether the same subcontractor can be compliant on one project and deficient on another at the same moment. If the system cannot represent that, it cannot represent your organization.

Does a parent company’s insurance cover its subsidiary on a federal contract?

Not automatically. Each legal entity in a holding company structure is its own contracting party with its own policies, licenses, and compliance record, and shared ownership does not merge them. If the contracting entity signs and a sister operating entity performs the work, the certificate has to name the party that actually carries the contractual obligation. A certificate naming the wrong entity is a real certificate for the wrong party.

Whose compliance record applies to a joint venture?

Both partners’ records and the joint venture’s own. FAR 9.104-3(c)(2) directs the contracting officer to consider the past performance of the joint venture, and where the joint venture has not demonstrated past performance for award, the past performance of each party to it. For SBA mentor-protege joint ventures, 13 CFR 125.8(e) requires the procuring activity to consider work done and qualifications held individually by each partner as well as work done by the joint venture itself.

How does a compliance requirement reach a third-tier subcontractor you have no contract with?

Only by being written into every contract between you and them. Under 29 CFR 5.5(a)(6) the contractor must insert the required clauses in its subcontracts along with a clause requiring subcontractors to include those clauses in any lower tier subcontracts. The same paragraph makes the prime contractor responsible for compliance by any subcontractor or lower tier subcontractor, so liability reaches a tier your paperwork often does not.

Can the same subcontractor be compliant on one project and non-compliant on another?

Yes, and treating that as a data error is the mistake. Insurance limits, endorsements, and licensing requirements are set by each project’s own prime contract, so a subcontractor approved at one project’s limits can be short of another project’s limits on the same day. Compliance is a property of a vendor on a specific project under a specific contract, not a property of the vendor.

Why does a spreadsheet per project fail for multi-entity contractors?

A spreadsheet per project stores compliance state correctly for one project and loses every relationship between projects. It cannot tell you which legal entity actually signed, which subcontractors appear on several jobs at different limits, or which of your subcontractor’s subcontractors exist at all. The data is not so much wrong as unjoinable, and the questions an auditor asks tend to span projects.

Your org chart is not a vendor list.

Contracts Connected keeps the entity, the project, and the contract as separate objects, so requirements live on the contract and compliance is tracked per project instead of per vendor. Our co-founder ran a large federal general contracting firm for 15 years, about 100,000 documents a year.

Book a demo


Sources

Contracts Connected is the AI Contract Operations System for construction.

See what it would take off your plate.

SOC 2 Type II · U.S. hosted · AI optional
Book a demo