Main contractors do not lose money on the head contract — they lose it in the gap between what a subcontractor claimed, what the quantity surveyor certified, what was actually paid, and what was withheld. In stock Odoo that gap is invisible. A subcontract package lives as a purchase.order, which assumes a quantity of goods delivered against a receipt; it has no concept of a schedule of values, a cumulative claim, a certified-this-period amount, or a retention percentage held against practical completion. Progress claims end up in a spreadsheet, retention lives in a QS's head, and back-charges (the crane hire you provided, the rectification you paid another trade to redo, the site clean-up levy) get remembered at final account time — or not at all. Odoo Enterprise's Project and Field Service apps track your own labour, not a third party's contractual entitlement, and no core model carries an expiry-dated insurance certificate that must block a payment.

What we build is a subcontract layer that sits beside Purchase and Accounting rather than fighting them. A new construction.subcontract model holds the package: the subcontractor partner, the parent project or analytic account, the contract sum, the retention rule (percentage held, percentage released at practical completion, percentage at end of defects liability), and a schedule-of-values line set with quantities, rates and a previously_claimed field. Against it, construction.subcontract.claim records each period's claim with @api.depends computes for amount_this_period, amount_cumulative, retention_held, back_charges_total and amount_certified_net — so the certified figure is derived, never typed. A statusbar workflow (draft → submitted → assessed → certified → invoiced → paid) is enforced by Python guards and by record rules in ir.model.access.csv plus ir.rule definitions, so a site engineer can assess but only a commercial manager can certify, and nobody can certify a claim whose cumulative value exceeds the contract sum plus approved variations. On certification we generate the vendor bill through the standard account.move API with the retention posted to a dedicated liability account and each back-charge posted as a negative line against its own account, so your trial balance, aged payables and project P&L all agree without a reconciliation exercise.

The compliance register is the part that pays for itself. construction.subcontract.document carries typed document slots — public liability and workers' compensation insurance, licence or registration number, tax clearance, method statement, RAMS, warranty — each with an issue date, expiry date and a computed is_valid. An ir.cron running nightly plus automated actions (base.automation) escalate at 30, 14 and 7 days before expiry to the buyer and the subcontractor's contact, and a configurable hard gate refuses certification while a mandatory document is expired. Reporting is QWeb: a payment certificate PDF suitable for issuing to the subcontractor, a retention statement per project, a back-charge schedule, and a subcontract cost-to-complete report reading through the analytic lines. Everything is exposed over XML-RPC and JSON-RPC with the standard search_read/create/write surface, so a site app, a Power BI dataset, or your existing document store can read and post without a custom endpoint. The module targets Odoo 17.0, 18.0 and 19.0 and is written against Community — Purchase, Accounting and Analytic are the only hard dependencies in __manifest__.py. If you run Enterprise we wire the optional hooks (Documents for file storage, Sign for the subcontract execution, Approvals for the certification chain) behind a soft dependency so the same codebase installs on either edition.

This is a build-to-order product, not an apps.odoo.com download. You request a quotation, we run a scoping call, and we write down the specifics that actually vary between builders: your retention percentages and release triggers, whether you certify against a schedule of values or a percentage-complete, how variations and provisional sums flow in, which back-charge categories exist, your document types and their expiry rules, and the exact chart-of-accounts codes for retention held and back-charges recovered. That scope becomes a fixed written specification before a line of code is committed. Typical delivery is one working week from confirmed scope, depending on how much of the claim workflow and reporting is bespoke.

Delivery runs on a staging copy of your database first. You get the installable source for your exact Odoo version, a UAT pass where your commercial team runs real claims through the workflow, and a documented rollback before we touch production. After go-live you have a support window for defect fixes, and the git repository is handed to you — the code is yours, so you are never locked to us for the next change.