Commercial general contractors ask me the same opening question almost every time: "can Acumatica actually produce our AIA pay application, or is that a spreadsheet we keep doing on the side forever?" It is a fair question — I have seen ERPs sell construction modules that turn out to be job costing with a construction-flavoured label. Acumatica Construction Edition is not that. The G702/G703 pay application is generated from the same contract, schedule of values, and job cost data the rest of the system uses, which is the part that actually matters for a GC running a dozen jobs at once.
The schedule of values is the spine, not a form
The instinct coming from a spreadsheet-based process is to treat the SOV as a document you fill in once a month. In Construction Edition it is a live structure tied to the project's cost codes and the original contract, and every approved change order updates it automatically. That means the pay app is a report over current data, not a re-typed summary — which is also why it is worth getting the schedule of values right at contract setup rather than patching it later.
Where the customization work actually lands
Out of the box, Construction Edition covers the pay application, retainage, commitments, and compliance document tracking (lien waivers, insurance certificates, bonds) reasonably well. The custom work I get hired for on commercial GC accounts is almost always at the edges: a client-specific pay app layout that matches their bank's exact G702 formatting, an integration that pushes released draws into a treasury or lender portal, or a validation that blocks releasing payment on a commitment when a subcontractor's insurance certificate has expired.
That last one is a small DAC extension worth showing, because it is the pattern I reuse across almost every commercial construction engagement:
public class APPaymentEntry_Extension : PXGraphExtension<APPaymentEntry>
{
protected virtual void APPayment_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
{
var payment = (APPayment)e.Row;
if (payment == null || payment.DocType != APDocType.Check) return;
foreach (APAdjust adj in PXSelect<APAdjust,
Where<APAdjust.adjdRefNbr, Equal<Required<APPayment.refNbr>>>>
.Select(Base, payment.RefNbr))
{
if (HasExpiredComplianceDoc(adj.AdjdBAccountID))
{
cache.RaiseExceptionHandling<APPayment.refNbr>(payment, payment.RefNbr,
new PXSetPropertyException("Vendor has an expired lien waiver or COI on file — release blocked.",
PXErrorLevel.Error));
}
}
}
}
Acumatica tracks compliance documents and expiration alerts natively. What it does not do out of the box is hard-stop a payment release for an expired document — that alert is informational unless you wire the enforcement yourself, on the payment graph, as above. Clients who assume "compliance tracking" means "the system won't let it happen" are usually assuming a customization that has not been built yet. Say so before the first missed lien waiver becomes a legal problem.
Wrapping up
For commercial GCs the honest pitch is: the pay application and commitment tracking are real, not bolted-on, and the ROI shows up the first month you stop re-keying a schedule of values into a Word template. The custom work is in the last mile — lender-specific formatting, enforcement rules, and integrations — and it is worth scoping that separately from the base implementation so nobody is surprised by it later.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.