Acumatica Sales Orders — From Quote to Invoice

The sales order lifecycle in Acumatica is really a chain of documents, not one screen doing everything: a quote becomes an order, an order becomes a shipment, a shipment (or the order itself) becomes an invoice. Where that chain starts and how tightly the steps are coupled is controlled by a handful of preference settings, and most of the "why doesn't this order invoice automatically" tickets I see trace back to one of those settings, not a bug.

The document flow: opportunity to invoice

The flow typically starts in CRM as an Opportunity, which can generate a Sales Quote. Converting the quote creates a Sales Order (SO301000) carrying over line items, pricing, and the customer record. From there, Shipments (SO302000) pull confirmed order lines for picking, packing, and confirming quantities shipped — this is also where lot/serial allocation and inventory issue transactions happen. The AR Invoice is the final document, and it can be generated either from the confirmed shipment or directly from the order, which is the single biggest fork in the process.

Invoice on Shipment vs. Invoice on Order

This is set per order type (and per customer, via order-related preferences) as the "Invoice Requires" or shipment-linkage setting. With Invoice on Shipment, the AR Invoice can't be created until a shipment for the order has been confirmed — the invoice inherits shipped quantities, which is the right model for anything physically fulfilled from stock, since you never bill for what hasn't left the warehouse. With Invoice on Order, the invoice can be generated straight from the Sales Order without a shipment step at all — this is how service items, non-stock lines, and drop-ship-billed-on-order scenarios get invoiced, since there's nothing to pick and pack. Mixing both behaviors on the same order type usually isn't what you want; it's cleaner to separate order types so the invoicing rule is a property of the order type, not something a user decides case by case.

Order types: SO, IN, CM, DM

Order types are how Acumatica differentiates document behavior on top of the same Sales Order screen. A standard SO type drives the quote-to-cash flow described above. An IN (Invoice) order type is often used for orders that skip shipment entirely — services, subscriptions, or anything billed directly. CM (Credit Memo) and DM (Debit Memo) order types handle returns and adjustments against a prior invoice, each with their own document numbering and GL posting behavior. Which order type a new order defaults to is itself a setting on the customer or the entry screen, so a common early customization is defaulting order type by customer class rather than making users pick it every time.

Statuses that drive the flow

Each Sales Order carries a status — Open, Completed, Invoiced, Cancelled, On Hold among others — and the status is what actually gates which actions are available, not the order type alone. An order stays Open while lines can still be shipped or edited; it moves toward Completed as shipments confirm against it; and once every line that requires invoicing has a matching AR Invoice, it flips to Invoiced. Trying to edit line quantities on a Completed order, or ship against a Cancelled one, is blocked by status, which is exactly the kind of guard rail that's tempting to work around with a customization — usually a mistake, since the status transitions are wired into GL posting and inventory allocation logic you don't want to bypass.

Common customization points

The two places I most often add logic to this flow are approval workflow and pre-shipment validation. Approval conditions on SO301000 (via the built-in Approval Maps against fields like order total or discount percent) route large or discounted orders to a manager before they can proceed to shipment — no code required if the standard condition builder covers the business rule. When it doesn't — say, blocking shipment confirmation unless a custom compliance field is populated — a PXGraphExtension on the shipment graph handling the row-persisting or the confirm-shipment action is the right layer, since it runs before the shipment can issue inventory and generate the downstream invoice.

public class SOShipmentEntry_Extension : PXGraphExtension<SOShipmentEntry>
{
    [PXOverride]
    public void ConfirmShipment(SOShipmentEntry.ConfirmShipmentDelegate baseMethod,
                                 List<SOShipment> list, bool isMultiple)
    {
        foreach (var shipment in list)
        {
            var order = PXSelectJoin<SOOrder,
                InnerJoin<SOOrderShipment,
                    On<SOOrderShipment.orderNbr, Equal<SOOrder.orderNbr>>>,
                Where<SOOrderShipment.shipmentNbr, Equal<Required<SOShipment.shipmentNbr>>>>
                .Select(Base, shipment.ShipmentNbr).RowCast<SOOrder>().FirstOrDefault();

            if (order?.GetExtension<SOOrderExt>()?.UsrComplianceChecked != true)
                throw new PXException("Compliance check must be completed before shipment confirmation.");
        }
        baseMethod(list, isMultiple);
    }
}

Wrapping up

Most quote-to-invoice questions come down to two decisions made early: which order type an order gets, and whether that type invoices on shipment or on order. Get those right per business scenario — physical goods on shipment, services on order — and the status-driven flow through SO301000, SO302000, and AR301000 mostly runs itself, leaving customization for the genuine exceptions like approval routing and pre-shipment compliance checks.