Acumatica AP Bill Screen — A Deep Dive

The Bills and Adjustments screen (AP301000) is where every payable in an Acumatica instance ultimately lands, whether it was typed in by an AP clerk or generated automatically by a three-way match against a Purchase Receipt. Underneath the UI it's a fairly conventional header/detail pair — APInvoice for the document header, APTran for the line items — but the graph behind it, APInvoiceEntry, carries a lot of business logic: tax calculation, GL distribution, retainage, and approval routing all hang off this one screen.

Where it sits in the process

A bill can arrive three ways: manual entry against a vendor, conversion from a Purchase Receipt (PO302000) via "Enter Bill," or import through an integration. Regardless of origin, the document moves through the same lifecycle — Balanced, then On Hold or Pending Approval, then Open once approved, then Closed once fully paid. The Financial Details tab is where branch, currency, and terms live; the Approval tab only appears when an approval map is assigned to the vendor's class or the document type. Release posts the batch to GL through APInvoice.Released and generates the corresponding GLTran rows behind the scenes — you don't see that batch directly from this screen, only its reference number.

Key tabs and what drives them

• Document Details — the APTran grid. Lines can be GL-account lines, PO-linked lines (populated from a receipt), or project/task lines when the Projects module is active.
• Financial Details — terms, due date calculation, and the cash discount date, all driven by the vendor's Terms ID unless overridden per document.
• Taxes — populated by the tax engine based on the vendor's tax zone/category combination; manual overrides here are a common source of tax report discrepancies later.
• Approval — only rendered when an Assignment/Approval Map applies; the underlying field is APInvoice.Approved plus rows in EPApprovalHistory.

Extending the graph

Most AP Bill customizations are graph extensions against APInvoiceEntry rather than DAC-only changes, because the interesting behavior is almost always "do something extra when a bill is saved or released." A typical pattern: validate a custom field on APInvoice during Persisting, or hook APInvoice_RowPersisting to block a save when a required custom attribute is blank for a given vendor class.

public class APInvoiceEntry_Extension : PXGraphExtension<APInvoiceEntry>
{
    [PXOverride]
    public void Persist(Action baseMethod)
    {
        APInvoice row = Base.Document.Current;
        if (row != null && row.DocType == APDocType.Invoice && row.UsrCostCenter == null)
            throw new PXSetPropertyException("Cost Center is required before this bill can be saved.");

        baseMethod();
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to the Financial Details tab is a standard DAC extension on APInvoice plus a placeholder in the ASPX (or, on modern screens, a JSON layout) — the Customization Project Editor's "Add Field" wizard handles both in one pass if you point it at the page. A whole new tab is a bigger ask: it usually means a related DAC (keyed to RefNbr/DocType) and a new PXTab bound to a data view on the graph extension, which is more work than most teams expect from what looks like a UI-only change.

Common validation and event-handler use cases

The recurring requests on this screen are: enforcing a custom approval threshold beyond what the built-in approval maps support, defaulting a subaccount segment based on a custom vendor attribute, and blocking release when a linked receipt hasn't been fully matched. All three are handled the same way — override or extend RowPersisting/RowSelected on APInvoice, or add a PXAction that runs before the standard Release action rather than trying to fight the release process itself.

Gotchas worth knowing before you customize this screen

Tax overrides entered directly on the Taxes tab don't retroactively recalculate if you change the tax zone afterward — clear and re-trigger the calculation instead of editing amounts by hand. Retainage, when enabled on the vendor or document, changes which fields on APTran actually flow to GL versus staying on the retainage sub-ledger, which trips up custom GL-distribution logic that assumes every line posts in full. And a bill created from a receipt inherits its branch and project from the receipt — overriding branch on the bill screen after the fact can silently break the three-way match reporting that finance relies on at month end.

Wrapping up

The AP Bill screen rewards restraint: most legitimate customizations are additive fields plus a validation rule or two, not a rewrite of how bills move through approval and release. Understand the APInvoice/APTran split, respect the release pipeline, and the screen stays maintainable across upgrades.