Acumatica AR Invoice Screen — A Deep Dive

Invoices and Memos (AR301000) is the AR mirror of the AP Bill screen, and it shows: the same header/detail shape, with ARInvoice holding the document and ARTran holding the lines, driven by the ARInvoiceEntry graph. The difference in practice is where the interesting logic lives — on AR it's less about matching and more about credit control, tax jurisdiction handling, and how tightly the invoice is linked back to a Sales Order or Shipment that generated it.

Manual invoices vs. generated invoices

Most invoices on this screen aren't typed by hand — they're produced by "Invoice Shipments" from SO302000 or by recurring billing schedules. A manually created invoice behaves the same as a generated one once it exists, but generated invoices carry an OrigModule/linkage back to the shipment or order, and customizations that assume every invoice line has a free-form description will break the moment someone runs the automated invoicing schedule.

Key tabs and what they touch

• Details — the ARTran grid, either GL-account lines or lines carried over from a shipment/sales order.
• Financial — terms, due date, and the customer's credit terms defaults, editable per document but sourced from Customer.
• Tax Details — populated from the customer's tax zone; overriding it here is the same trap as on the AP side — it doesn't survive a recalculation.
• GL Transactions — read-only, populated once the invoice is released; useful for confirming a customization's GL distribution logic actually did what it was supposed to.

Graph extension patterns worth knowing

The most common AR Invoice extension is a credit-limit-adjacent check that goes beyond the stock hold behavior — for example, blocking release for a customer flagged in a custom "collections" status field, rather than relying solely on the built-in credit limit and terms hold. That's a RowPersisting or a pre-release action override on ARInvoiceEntry, same shape as the AP side.

public class ARInvoiceEntry_Extension : PXGraphExtension<ARInvoiceEntry>
{
    protected virtual void ARInvoice_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
    {
        var row = (ARInvoice)e.Row;
        if (row == null) return;

        Customer cust = PXSelect<Customer,
            Where<Customer.bAccountID, Equal<Required<Customer.bAccountID>>>>
            .Select(Base, row.CustomerID);

        if (cust?.GetExtension<CustomerExt>()?.UsrOnCollectionsHold == true && row.Released != true)
            cache.RaiseExceptionHandling<ARInvoice.hold>(row, true,
                new PXSetPropertyException("Customer is flagged for collections review.", PXErrorLevel.Warning));
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to Financial or Details is the routine DAC-extension-plus-layout-change pattern. Where teams get into trouble is adding a field that needs to appear on the printed invoice as well as the screen — the report (Report Designer, not the screen editor) needs its own binding to the same extension field, and it's easy to ship a customization that works on-screen but never reaches the PDF customers actually see.

Common validation and event-handler use cases

Beyond credit holds: defaulting a custom "invoice reason" field based on the originating sales order type, enforcing a minimum invoice amount for certain customer classes, and syncing a custom field back to the originating Shipment once the invoice is released (useful for reporting that needs to trace a shipment all the way to payment). All three sit comfortably in a graph extension without touching the base DAC.

Gotchas

An invoice generated from a shipment inherits its line-level tax category from the stock item, not the customer — a custom validation that only checks the customer's tax zone will miss item-level tax overrides. Reversing a released invoice doesn't delete it; it creates a debit memo and leaves the original Closed, which surprises people expecting a hard delete. And because ARInvoiceEntry is also the base graph for Credit Memos and Debit Memos (differentiated by DocType), a validation written without a doc-type filter can silently fire on documents it was never meant to touch.

Wrapping up

The AR Invoice screen looks like a data-entry form but carries the weight of credit control, tax jurisdiction rules, and the audit trail back to whatever sales process produced the document. Customizations that respect the DocType boundary and the release pipeline stay stable; ones that treat every ARInvoice row as a hand-typed invoice eventually break on a batch of auto-generated ones.