Acumatica Customer Credits and Memos

A client's collections team once asked me why a customer with a large unapplied credit memo kept showing up on the aged receivables report as past due. The credit was real, it was released, and it was sitting right there in the customer's balance. The problem was that nobody had applied it to the open invoice, and Acumatica does not do that for you automatically just because a credit exists. Credits and memos are one of the areas where the AR module's flexibility is also its biggest foot-gun, so here's how the pieces actually fit together.

AR Credit Memo vs Debit Memo vs Cash Return — three different documents

Acumatica's AR module gives you several document types that all adjust a customer's balance, and picking the wrong one produces correct-looking numbers with wrong downstream behavior. A Credit Memo (document type CRM on ARInvoice, which is the same DAC that backs invoices, debit memos, and credit memos, distinguished by DocType) reduces what the customer owes and can be applied against one or more open invoices. A Debit Memo (DRM) does the reverse, increasing the balance, and is used for things like a bounced-check fee or a shipping adjustment discovered after invoicing. A Cash Return lives in Cash Management, not AR, and represents money physically leaving the company back to the customer rather than a balance adjustment sitting on their account.

The distinction that trips people up: a credit memo does not require the customer to have ever paid anything. You can issue a credit memo purely to reduce an outstanding invoice balance, with zero cash ever changing hands, and it clears through AR application, not through Cash Management at all.

PXSelect<ARInvoice,
    Where<ARInvoice.customerID, Equal<Required<ARInvoice.customerID>>,
    And<ARInvoice.docType, Equal<ARDocType.creditMemo>>,
    And<ARInvoice.released, Equal<True>>,
    And<ARInvoice.openDoc, Equal<True>>>>
    .Select(Base, customerID);

OpenDoc is the field that matters here. A released credit memo with OpenDoc = true and a nonzero CuryDocBal is money sitting on the account, unapplied, doing nothing for the customer's aging until someone applies it.

Application is a separate step, and it is where most credit memos get stuck

Creating and releasing a credit memo only makes the balance exist. Reducing a specific invoice's open amount requires an explicit application, done either on the Invoices and Memos screen's Applications tab at entry time, or later via the Apply Payments/Credit Memos screen. Programmatically this goes through ARPayment's adjustment mechanism even for a pure memo-to-invoice application with no cash involved, because the framework models all AR application, cash or not, through the same adjustment infrastructure.

ARPaymentEntry graph = PXGraph.CreateInstance<ARPaymentEntry>();
graph.Document.Current = graph.Document.Search<ARPayment.refNbr>(creditMemoRefNbr, ARDocType.creditMemo);

ARAdjust2 adj = new ARAdjust2
{
    AdjdDocType = ARDocType.invoice,
    AdjdRefNbr = invoiceRefNbr,
    AdjAmt = amountToApply
};
graph.Adjustments.Insert(adj);
graph.Save.Press();
graph.releaseFromHold.Press();

Write-offs are not credit memos, and mixing them up creates a GL mess

A small balance write-off (the seventeen cents left after a payment that didn't quite match the invoice, or a genuinely uncollectible balance a manager approves clearing) uses the write-off mechanism on the Apply Payments screen, which posts to a configured write-off account, not the AR account a credit memo's offsetting GL entry hits. Building a custom "auto write-off" routine that instead issues a credit memo for small balances will technically clear the AR aging, but it posts to the wrong GL account and misrepresents what actually happened financially. If a client wants automated write-off logic, drive it through the framework's write-off fields on ARAdjust2, not by synthesizing credit memos in code.

Why finance teams care about this beyond just aging

Unapplied credit memos are real liabilities sitting in AR that distort both the aging report and cash flow projections built from it — the customer's true outstanding balance is lower than the raw invoice total suggests, but a naive report that only sums open invoices without netting open credits overstates what's actually collectible. On one implementation I built a scheduled Generic Inquiry specifically to surface customers with unapplied credits older than 30 days, because the collections team had no visibility into memos sitting idle, and it directly reduced the number of "why is this customer overdue" escalations by giving them something to act on instead of just a raw aging number.

Wrapping up

Credit and debit memos live on the same DAC as invoices, distinguished only by document type, but they behave very differently once released: they don't net against anything until explicitly applied, and application is a distinct step from creation that's easy for a process to skip. Keep write-offs on the write-off mechanism rather than faking them with memos, and if your client's collections process depends on unapplied credits being visible, build reporting for it explicitly, because the standard aging report won't surface it for you.