Acumatica Vendor Screen — A Deep Dive

Vendors (AP303000) is the AP counterpart of the Customer screen, built the same way: Vendor is an extension of BAccount, maintained through the VendorMaint graph, with class-based defaults (VendorClass) inherited once at creation. Anyone who's worked through the Customer screen's quirks will recognize most of Vendor's — the difference is in the tabs that matter, which lean toward remittance, tax reporting, and purchasing defaults instead of credit and statements.

Vendor, BAccount, and VendorClass

Payment terms, default AP accounts, and 1099 reporting settings all come from VendorClass at creation and don't retroactively update if the class changes later — the same inheritance rule as Customer/CustomerClass. A vendor that also happens to be a customer (a supplier the company also sells to) is still, underneath, one BAccount row that can carry both a Vendor and a Customer extension — worth knowing before building a customization that assumes vendors and customers are always mutually exclusive.

Key tabs

• General — identity, addresses, and primary contact, shared with the underlying BAccount.
• Financial — terms, default AP accounts, and the currency this vendor is expected to bill in.
• Tax — tax zone, exemption info, and (in US instances) 1099 box mapping.
• Remittance — the address/contact used specifically for payment, which frequently differs from the general address.
• Purchase Settings — default warehouse, lead time, and other fields that pre-populate new Purchase Orders for this vendor.

Extending VendorMaint

1099 reporting is a recurring source of customization requests — box mapping that doesn't match a company's actual vendor mix, or a need to flag certain vendors for backup withholding logic beyond what ships out of the box. That kind of validation belongs on the Vendor extension, checked at the point a bill is entered against the vendor rather than only at year-end reporting time, so problems surface immediately rather than during 1099 season.

public class VendorMaint_Extension : PXGraphExtension<VendorMaint>
{
    protected virtual void Vendor_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
    {
        var row = (Vendor)e.Row;
        if (row?.Vendor1099 == true && string.IsNullOrEmpty(row.TaxRegistrationID))
            throw new PXSetPropertyException("A tax ID is required for vendors flagged as 1099.");
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to Financial or Purchase Settings is routine. As with Customer, decide whether a new field belongs on the Vendor extension or the base BAccount, particularly for anything that would also need to appear if the same BAccount later gets an Employee or Customer extension attached.

Common validation and event-handler use cases

Beyond 1099 validation: enforcing a secondary approval before a vendor's remittance bank details can change (a common fraud-prevention control, since payment redirection scams typically target exactly this field), restricting VendorClass selection to values appropriate for the vendor's country, and blocking new POs against a vendor flagged On Hold beyond the standard hold check, for custom compliance statuses.

Gotchas

Vendor status (Active/Hold/Inactive) affects new document creation but doesn't retroactively touch documents already in progress — an On Hold vendor can still have an open PO or unreleased bill sitting untouched. Remittance address defaults independently from the general address; a customization assuming payments always go to the address shown on General will send checks or ACH to the wrong place if Remittance was configured separately. And because Vendor shares BAccount with Customer and Employee, restriction groups and BAccount-level security apply uniformly — a security model designed only around AP roles can be circumvented if BAccount-level restrictions aren't also considered.

Wrapping up

Vendor mirrors Customer's architecture closely enough that most lessons transfer directly, with the added weight of payment fraud risk around remittance details and 1099 compliance around tax settings. Customizations that add friction to those two areas specifically are almost always worth the extra clicks they cost.