AIA billing and progress invoicing in Sage Intacct: A step-by-step guide

The pay application is due Friday. The percent-complete update from the field came in late, one change order is still waiting on an approved billing status, and the retainage exception lives in a spreadsheet only one person understands. Accounts receivable has not even started the invoice, and the billing is already behind.

That is the pattern in AIA-style billing: the pay application is the printout at the end, and everything that makes it right happens earlier. Contract value, schedule of values, approved changes, current progress, and retainage all have to be settled before AR can build a package anyone should sign. Get that data right and the document follows.

We sat down with Troy Guevara, Construction Technologist at Alta Vista Technology, who focuses on Sage Intacct Construction implementations. We implement and support construction ERP systems for a living, and Troy’s view matches what we see in project after project: if your team cannot name the owner for percent complete, change-order billability, and retainage exceptions, you are not ready to configure progress billing yet.

Sage Intacct Construction may be a strong fit when progress billing has to live inside construction accounting, project controls, approvals, and reporting. The exact owner-facing AIA-style package still needs to be validated with your required forms, backup documents, retainage rules, and approval path before you assume the workflow is covered.

Why we say AIA-style billing

AIA billing is common shorthand for a construction progress billing package based on widely used AIA pay application practices and construction-standard forms. AIA Contract Documents describes its contracts and forms as recognized industry-standard documents for the parties on a project: architects, contractors, engineers, attorneys, and owners.

That does not mean every owner wants the same package. One contract may require stored-material detail. Another may require specific backup, lien-waiver support, signatures, or a different approval sequence. We say AIA-style billing here because what you have to satisfy is your own owner package, with all its quirks, and a generic invoice label hides those.

When you evaluate an ERP, test one thing: can your system and process produce billing data that is complete, approved, and traceable before the pay application goes out?

What AIA-style progress billing requires from your ERP

A useful ERP workflow has to carry the billing basis from project setup through posting and reporting. At a minimum, your team should be able to settle these inputs before AR releases the billing package:

• Original contract value and approved revisions
• Prior billings by line
• Current work completed or percent complete
• Approved change orders that are allowed to affect the current billing basis
• Stored materials, if the contract requires that detail
• Retainage withholding, exceptions, reductions, and releases
• Required backup documents and review evidence
• AR posting, retainage receivable, job-cost, and WIP reporting impact

If those inputs are late or inconsistent, the pay application will be late or inconsistent. AR can format and post approved billing data. AR should not have to guess whether a change order belongs in this month’s pay application or whether the work is complete enough to bill.

Make sure you are looking at the construction edition

Confirm at the outset which product you are being shown. Sage Intacct has a standard edition that suits plenty of organizations, but AIA-style progress billing for contractors depends on construction accounting and project controls that live in the construction edition. Test how billing connects with job costing, project financials, cost codes, change management, retainage, compliance context, approvals, and reporting.

What should you test with one real project?

Use one real job to walk through the billing process before you accept a demo or finalize configuration. The goal is to prove that the contract, schedule of values, change orders, retainage, approvals, AR posting, and reporting all tell the same story.

The workflow holds together when ownership is settled before billing starts. Where it stays vague, the work still moves, but no one can tell you who is running late on it. The posted invoice should tie back to the same project story your controller, project manager, and executive team see in reporting.

Which controls decide what you can bill

The form of the invoice is the last thing to settle. First you control the billing basis. The controls below decide what is allowed to be billed, who can approve it, and whether the posted result can be trusted.

Change-order billability

Define the status that makes a change order billable. Draft, submitted, approved, rejected, and internal budget revision should not all behave the same way. Your labels can vary, but the rule cannot be fuzzy. When it is fuzzy, a change either gets billed before the owner approved it or sits unbilled while the work is already done.

Percent-complete ownership

The project team should own progress because they know the work. Finance should review consistency and posting impact. AR should not estimate completion because the project team missed the cutoff.

A simple ownership rule helps: project management owns progress, finance owns billing consistency and posting, and leadership owns cutoff enforcement.

Retainage exceptions

Retainage needs a documented rule for withholding, reduction, and release. Exceptions by line, phase, owner requirement, or project milestone should be visible before the billing package is approved. Manual retainage notes outside the system are a common source of rework because the posted invoice can drift away from the report finance relies on.

Cutoff and job-cost freshness

Billing confidence drops when AP, labor, subcontractor invoices, or job-cost data are stale at cutoff. Troy described the accountability shift this way: “If my job cost report isn’t current, and I’ve got invoices sitting in the queue waiting for my approval, that’s on me. I can see it. It puts accountability where it belongs.”

The same principle drives progress billing. A system can show late inputs and stuck approvals. Managers still have to enforce the cutoff.

What should you bring to a Sage Intacct Construction demo?

A generic demo will not prove whether your billing package works. Bring the people who own the work: the controller or CFO, AR or project accounting, a project manager or project executive, and the person who understands connected systems such as project management, estimating, AP, payroll, or document storage. Then ask questions that force the demo to follow your billing path:

• Owner package: Can we see how our required AIA-style package would be produced, including what is native, configured, templated, exported, or handled through a connected process?
• SOV and job cost: How would our billing lines connect to our project, phase, cost-code, and reporting structure?
• Change orders: What status makes a change billable, and how are pending, approved, rejected, and internal-only changes kept separate?
• Retainage: How are withholding, reductions, exceptions, and releases controlled so project accounting is not maintaining separate notes?
• Progress updates: Who enters current work completed, who approves it, and what prevents AR from releasing a package before that approval is captured?
• Posting and reporting: After posting, how do AR, retainage balances, project reports, and WIP reporting agree?
• Connected systems: Which project management, estimating, payroll, AP, or document systems affect the billing process?
• Historical billing: What prior billing detail should move into Sage Intacct Construction, and what should remain in archived reports?

Troy recommends asking implementation partners three questions early: “What does data migration look like? Can we connect third-party platforms? What do we need to change to make this system work for us?”

The last question is the one many teams avoid. It is also the one that determines whether Sage Intacct Construction improves billing control or becomes a new place to store the old spreadsheet process.

Checklist before you configure progress billing

Use this as implementation preparation, not a full project plan. If your schedule of values, retainage, change-order, and percent-complete ownership rules are not settled, pause before treating configuration as the first step.

What breaks first?

The first thing to break is usually the team recreating the old spreadsheet process inside the new ERP. That matters in AIA-style billing because the old way often depends on one person who remembers the contract quirks, owner preferences, spreadsheet formulas, and unofficial approval path.

Watch for these signs that the process is not ready:

• Billing lines do not match how the project is budgeted, costed, or reported.
• Change orders sit in unclear statuses, so finance does not know what is billable.
• Percent complete is updated after the billing cutoff.
• Retainage exceptions are handled manually outside the system.
• Project managers review the package after AR has already built it.
• Supporting documents are gathered only after the owner asks for them.
• Historical billing data is migrated without a clear reporting or audit reason.
• AP, labor, or subcontractor costs are too stale for the project team to trust the job-cost picture.

This is where you have to be honest about what Sage Intacct Construction will and will not fix. If all you need is cleaner invoice formatting, a full construction ERP project is a heavy way to get there. If your billing issue is unclear ownership, the software will make late inputs and broken approvals easier to see, and leadership still has to decide who owns the work.

Don’t build the process around the final form

A reliable AIA-style billing process starts with contract setup, billing structure, approved change control, progress ownership, retainage rules, and review authority. Design around those and the owner-facing package falls out of them. A process designed around the package instead spends the whole implementation forcing the controls to catch up.

So before you open any feature checklist, do this: choose one real project, trace it from contract setup through AR posting and reporting tie-out, and confirm each input has an owner your team can name. If they cannot, fix the process before you configure anything.