Acumatica Cash Management — Extension Patterns

Cash Management is the module people forget about until a bank feed reconciliation goes wrong. It's smaller than AP or AR in terms of screen count, but the extension points around bank transaction matching and cash account reconciliation are some of the more finicky ones in the product because the matching logic has to reconcile imperfect external data against clean internal records.

Core DACs and screens

The central DACs are CashAccount, CATran (cash transactions), and CashTransfer for inter-account moves. Bank reconciliation runs through the Reconciliation Statements screen (CA304000), backed by the graph StatementEntry, and transfers go through CashTransferEntry. If the client is on bank feed integration, imported bank lines land in a staging structure before being matched against CATran — the matching algorithm itself is not something you want to reimplement wholesale.

Where extensions attach

A PXGraphExtension<StatementEntry> is the natural home for custom matching rules — for example, matching an imported bank line to an existing CATran by a reference number embedded in the bank's memo field rather than by amount and date alone, which is the stock matching heuristic. This is typically done by adding a scoring step before the built-in auto-match runs, or by extending the match criteria the built-in logic already considers.

A realistic scenario: reference-number matching

A frequent CM ask: the client's bank feed includes a payment reference in the description field that maps to an internal check number or wire reference, and the stock date/amount matching produces too many false positives when multiple payments clear on the same day for the same amount.

public class StatementEntry_RefMatch_Extension : PXGraphExtension<StatementEntry>
{
    protected virtual void CABatchDetail_RowSelected(PXCache sender, PXRowSelectedEventArgs e)
    {
        var detail = (CABatchDetail)e.Row;
        if (detail == null || detail.TranID != null) return; // already matched

        string refFromMemo = ExtractReference(detail.ExtTranID);
        if (string.IsNullOrEmpty(refFromMemo)) return;

        var candidate = PXSelect<CATran,
            Where<CATran.extRefNbr, Equal<Required<CATran.extRefNbr>>,
                And<CATran.cleared, Equal<False>>>>
            .Select(Base, refFromMemo).RowCast<CATran>().FirstOrDefault();

        if (candidate != null)
        {
            detail.TranID = candidate.TranID;
            sender.Update(detail);
        }
    }

    private string ExtractReference(string memo) => memo?.Split(':').LastOrDefault()?.Trim();
}

This runs as a supplementary matcher on records the stock logic left unmatched, which is the safer integration pattern — it never overrides a match Acumatica already made with confidence.

Cash transfers and multi-account scenarios

Custom approval or notification requirements on CashTransferEntry (say, requiring a second sign-off above a threshold before a transfer posts) follow the same approval-map pattern used elsewhere in financials — it's a condition on the CashTransfer DAC, not bespoke code, unless the condition needs data outside what the transfer record exposes.

Testing considerations

Reconciliation extensions need to be tested against a full statement import, not a handful of hand-entered rows — false matches and duplicate matches are almost always a volume problem, showing up only once a statement has enough same-day, same-amount transactions to create ambiguity. Test with at least one statement pulled from production-like data before shipping a custom matcher.

Wrapping up

Cash Management extensions are lower-volume but higher-precision than AP or AR work — a matching rule that's slightly wrong doesn't throw an error, it silently mismatches a transaction, which is worse. Build custom matching as an addition to the stock matcher, and validate against real statement volume before trusting it in production.