Acumatica Projects — Time and Expense Capture

Project accounting in Acumatica lives or dies on capture. The billing rules, WIP reports and profitability dashboards are all downstream of one unglamorous question: do time and expenses actually get recorded, promptly, against the right project and task? I've implemented the Projects module for engineering firms and a services company, and in every case the configuration took a week while the capture discipline took a quarter. Here's how the machinery works and where it fights you.

The capture pipeline

Time flows through time cards (or the simpler time activities), expenses through expense claims and expense receipts. Both end up as PM transactions — the atomic unit of project accounting, living in PMTran — tagged with project, project task, cost code (if enabled), inventory item (for labor, a non-stock item representing the labor type), and account group. Billing rules later read those PM transactions to build invoices; the account group is the pivot the whole thing turns on, so mis-mapped account groups are the number one cause of "billable time that never billed."

Time entry: what users actually tolerate

Acumatica gives you employee time cards (EP305000) on a weekly grid, time activities attached to cases/tasks/events, and mobile entry through the Acumatica app. Some hard-won guidance:

• Restrict the project/task lookup. Out of the box, users can log time to anything. Project attributes and visibility settings on the project (which employees are on the team) cut the lookup to relevant projects. Every implementation where I skipped this, timesheets grew mystery entries against closed or wrong projects.
• Labor items map to cost rates. The non-stock labor item plus the employee's labor rate table (EP.20.30.00-style rate tables by employee, labor item, project) decide the cost the PM transaction carries. If the rate table has gaps, time posts at zero cost and the project margin report lies to you.
• Approval before release. Time cards route through the approval map — typically project manager approval. Keep it to one level. Two-level time approval sounds rigorous and just delays cost recognition by a week.
• Mobile matters more than you think. Field staff enter time the same day when it's three taps on a phone, and on Friday-from-memory when it's a desktop grid. The mobile time entry screens are configurable through the mobile site map; trimming them to the four fields that matter doubles same-day capture.

Expenses: receipts, claims and corporate cards

The expense flow is receipt → claim → release, and the mobile app's receipt capture (photograph the receipt, OCR pre-fills amount and date on recent versions) is genuinely the best part of the module. Configuration points that matter:

• Expense items drive GL and billability. Each expense type is a non-stock item whose expense account and account group determine posting and whether billing rules pick it up. Mark-up percentages for rebillable expenses live here too.
• Corporate card support separates "paid by employee, reimburse them" from "paid by company card, don't." Getting this wrong double-pays people; the corporate card feature exists so you don't hand-net it.
• Receipt required thresholds and policy limits can be enforced with a small validation — a RowPersisting handler on the claim that blocks lines over a limit without an attachment.

protected virtual void _(Events.RowPersisting<EPExpenseClaimDetails> e)
{
    var row = e.Row;
    if (row == null || row.CuryTranAmt <= 50m) return;

    // require an attachment (receipt) above the threshold
    var noteFiles = PXNoteAttribute.GetFileNotes(Base.Caches[e.Row.GetType()], row);
    if (noteFiles == null || noteFiles.Length == 0)
        throw new PXRowPersistingException(
            nameof(EPExpenseClaimDetails.curyTranAmt), row.CuryTranAmt,
            "Receipts over 50 require an attached image.");
}

From capture to project cost

On release, time cards and expense claims generate PM transactions (and GL entries per the posting setup). Watch two things in the first month of go-live: unreleased documents piling up (a GI listing open time cards and claims older than N days, on the PM's dashboard, fixes this socially), and the date the cost lands — PM transactions carry the transaction date, so late-entered time distorts week-by-week burn charts even when totals are right. The cure is capture discipline, not configuration.

What good looks like

A healthy install has: same-day or next-day time entry above 80%, expense claims released within a week, zero PM transactions with missing account groups, and a project manager who checks the committed-vs-actual dashboard without being asked. Every one of those is measurable with a Generic Inquiry, and I set the four of them up as dashboard KPIs during go-live so the slide back into old habits is visible immediately.

Wrapping up

The Projects module's capture machinery — time cards, expense claims, PM transactions, account groups — is solid and flexible. The failure modes are almost all upstream of the software: unrestricted lookups, gap-ridden rate tables, unreleased documents, and slow entry habits. Configure the guardrails, trim the mobile screens, put staleness on a dashboard, and the billing and profitability layers downstream get dramatically easier.