Acumatica Project Billing Rules — Progress, Milestone, and More

Billing rules are the most underrated piece of Acumatica's Projects module. Most implementations copy the demo T&M rule, attach it to every task, and then handle every non-trivial billing arrangement manually with credit memos and apologies. That's a waste, because the billing rule engine — steps, filters, formulas, rate tables — can express almost any commercial arrangement I've met: time and material, fixed price on progress, milestones, cost-plus with caps, and combinations per task. Here's how the pieces fit and the patterns I actually deploy.

How a billing rule executes

A billing rule (PM207000) is a set of steps. Each step is one of two types: Time and Material steps read unbilled PM transactions filtered by account group and turn them into invoice lines; Budget steps read the project budget (revenue budget lines) and bill an amount — typically pending invoice amounts you set through progress or a formula. When you run Project Billing (PM503000 or the Bill button on the project), each task's assigned rule executes step by step, and the output is a pro-forma invoice (if enabled) or a draft AR invoice.

Because the rule attaches per task, one project can mix arrangements: task 010 fixed-price on milestones, task 020 T&M for change orders, task 030 rebillable expenses at cost plus 10%. That per-task composition is the design insight most people miss.

T&M steps: the workhorse

A T&M step's essentials: the account group filter (which PM transactions it consumes — typically LABOR and a rebillable expense group), the rate type, and the invoice description formula. Rates deserve attention. Rate tables (PM206000) resolve a price from a sequence of criteria — rate type, then rate code sequences matching project, task, employee, labor item — and the first matching sequence wins. My advice: keep the sequence hierarchy shallow (project-specific overrides, then a standard rate by labor item) and document it, because debugging "why did this hour bill at the wrong rate" through a five-level rate table is genuinely painful.

Formulas on the step control line aggregation and descriptions. A description formula like this keeps invoices readable:

=[PMTran.Date] + ' - ' + [EPEmployee.AcctName]
  + ' - ' + [PMTran.Description]

Aggregate by employee and date for professional-services invoices; itemize per transaction for audit-heavy clients. It's a checkbox-level change with a big effect on how many invoice disputes you field.

Progress billing (fixed price)

Budget steps bill from the revenue budget. The standard fixed-price pattern: put the contract value on revenue budget lines, and each period the PM enters completed % (or a pending invoice amount directly) on the project's revenue budget tab. The budget step picks up the pending amount and invoices it. Two operational notes:

• Completion percentage is a manual judgment unless you wire it to something. For clients who want cost-driven progress, a small customization sets pending % from actual cost ÷ cost budget — but cap it, because overruns would otherwise happily bill 130% of contract.
• The pro-forma invoice step is where the PM trims or defers lines without corrupting project data — amounts removed on the pro-forma stay unbilled and return next cycle. Skipping pro-formas to "save a step" removes the only safe adjustment point in the flow.

Milestone billing

Milestones are progress billing with discipline. Model each milestone as its own revenue budget line (or its own task, if deliverables need separate cost tracking): "Milestone 1 — Design sign-off, 30,000." When the milestone is achieved, set that line's pending amount to 100% and bill. The reason to prefer lines-per-milestone over one line with creeping percentages is auditability — the invoice shows the milestone by name, and an argument with the customer becomes "was this delivered," not "is 47% fair."

Cost-plus and caps

Cost-plus is a T&M step over cost account groups with a markup formula (multiply the amount, or use the rate table with a % markup rate type). Contract caps — "T&M not to exceed 50,000" — use the limits feature: set a maximum amount tied to the revenue budget, and billing stops at the cap while the excess stays as unbilled WIP for the uncomfortable conversation it deserves.

Testing a billing rule

Before attaching a rule to live projects, I build one sandbox project per arrangement and run a full cycle: post known time/expenses, run billing, verify the pro-forma line by line, release, check AR and the project's billed-to-date. Billing rules fail quietly — a wrong account group filter doesn't error, it just silently bills nothing — so the test isn't "does it run," it's "does every transaction I expected appear, and nothing else."

Wrapping up

Compose per task: T&M steps for effort, budget steps for fixed-price and milestones, rate tables kept shallow, pro-formas always on, limits for caps and retainage where the contract demands it. The engine can express the contract you actually signed — the work is mapping the commercial terms onto steps deliberately instead of forcing everything through one copied T&M rule.