Prepayments and deferrals are two sides of the same timing problem, cash or an invoice hitting the books before the revenue or expense it represents is actually earned or incurred, and Acumatica handles them through two genuinely different mechanisms that get confused constantly by developers coming from a simpler accounting background. Prepayments are a document-level AR/AP feature. Deferrals are a schedule-driven GL recognition engine. Knowing which one a client actually needs saves a lot of wasted customization effort.
AR Prepayments: cash collected before an invoice exists
An AR Prepayment Invoice (or a prepayment recorded directly against a Sales Order) lets you collect a deposit before the goods ship or the service is delivered, without that cash inflating revenue prematurely. The prepayment posts to a prepayment liability account, not revenue, and when the actual invoice is later generated, the prepayment applies against it the same way a credit memo would, reducing the amount due. This is the correct pattern for deposit-driven businesses, custom manufacturing with upfront deposits, project work requiring a retainer, without which revenue would be recognized the moment cash arrived rather than when it's actually earned.
ARPaymentEntry graph = PXGraph.CreateInstance<ARPaymentEntry>();
graph.Document.Current = graph.Document.Search<ARPayment.refNbr>(prepaymentRefNbr, ARDocType.prepayment);
ARAdjust2 adj = new ARAdjust2
{
AdjdDocType = ARDocType.invoice,
AdjdRefNbr = invoiceRefNbr,
AdjAmt = graph.Document.Current.CuryUnappliedBal
};
graph.Adjustments.Insert(adj);
graph.Save.Press();
The GL impact is a debit to cash and a credit to a prepayment liability account at collection time, and only when applied does the liability reverse into the AR/revenue side. Skip this pattern and build a customization that posts a prepayment straight to a revenue account "for simplicity" and you've created a real revenue recognition problem that will surface at year-end audit, usually described politely as "premature revenue recognition."
AP Prepayments: the mirror image, and easy to under-build
AP works the same way in reverse, a prepayment to a vendor (a deposit on a large purchase order, a retainer to a contractor) posts to a prepaid expense or vendor deposit asset account, not directly to expense, and applies against the vendor bill once it arrives. I've seen implementations skip the formal AP prepayment mechanism and instead code the deposit as a regular AP bill against an expense account "to keep it simple," which understates assets and overstates expense in the period the deposit was paid rather than the period the goods or services were actually received. It's a five-minute setup to configure the prepayment account correctly; unwinding a year of misclassified deposits at audit time is not five minutes.
Deferred Revenue/Expense: schedule-driven recognition, a genuinely different engine
Deferrals solve a different problem: not "cash arrived before the invoice," but "the invoice/bill is fully valid and posted, but the revenue or expense it represents should be recognized gradually over a future period," a twelve-month subscription invoiced up front, a prepaid insurance bill covering the coming year. Acumatica's Deferred Revenue Accounting (and the equivalent expense deferral) works through Deferral Codes attached to a line item or GL account, which define a recognition schedule, straight-line, or a custom schedule, and the framework automatically generates the recognition journal entries period by period as the schedule runs.
protected virtual void _(Events.RowInserted<ARTran> e)
{
if (e.Row == null) return;
if (e.Row.InventoryID == subscriptionItemID)
{
e.Row.DeferredCode = "12MO-SL"; // straight-line over 12 periods
e.Cache.SetValueExt<ARTran.deferredCode>(e.Row, e.Row.DeferredCode);
}
}Once a deferral schedule is created against an invoice line, recognizing it each period requires running the deferral recognition process (manually or on a schedule via the Automation Schedules feature) for each open period, it does not happen automatically just because the calendar rolled over. On instances I've supported where nobody wired up the automation schedule, deferred revenue quietly piled up unrecognized for months until someone in finance noticed the deferred revenue balance sheet account never moved.
Deciding which mechanism a requirement actually needs
The question that resolves most of the confusion: is the timing problem about when cash/invoice exists relative to when the transaction is finalized (use prepayments), or about when a fully valid, already-posted transaction's revenue/expense should hit the income statement (use deferrals)? A retainer collected before any invoice exists is a prepayment. A fully invoiced annual maintenance contract that should recognize revenue monthly over the contract term is a deferral. Some real-world scenarios need both in sequence, a deposit collected as a prepayment, then applied against an invoice whose service line itself carries a deferral code for gradual recognition, and building that combined flow correctly is where a lot of subscription and project-billing customizations actually live.
Wrapping up
Prepayments and deferrals solve related but distinct timing problems and Acumatica gives you two different, purpose-built mechanisms rather than one general "recognize this later" tool. Route deposits through the formal AR/AP prepayment document types rather than faking them with regular invoices against the wrong account, use deferral codes for revenue or expense that's already validly posted but needs to spread over future periods, and don't assume deferral schedules recognize themselves without an automation schedule actually running them.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.