Acumatica Cash Transaction Screen — A Deep Dive

Cash Transactions (CA304000) is where money movement that isn't tied to an AR or AP document gets recorded directly against a cash account — bank fees, interest income, transfers between accounts, or a manual entry made while reconciling a statement. The graph is CashTranEntry, backed by the CATran DAC. It's a smaller screen than the invoice-heavy ones, but it's the one most closely tied to bank reconciliation accuracy.

How it differs from AR/AP cash entries

Payments and receipts tied to a customer or vendor normally flow through AR/AP payment screens, which post to cash accounts indirectly. This screen is for the residual category — transactions with no AR/AP document behind them. A customization that reconciles "all cash activity" by reading only this screen will miss the majority of actual cash movement, which comes through Payments and Applications instead.

Key tabs

• Details — the CATran grid: cash account, transaction type (receipt/disbursement/transfer), amount, and offsetting GL account.
• Financial — currency and reference information used for reconciliation matching against imported bank statement lines.

Extending CashTranEntry

The most common customization is enforcing a two-step approval for disbursements above a threshold — since this screen can move money without an AR/AP document as a paper trail, some organizations want a stricter control here than they apply to normal AP payments. Another is auto-categorizing transaction types based on a description pattern, useful when a bank feed import lands many small transactions here for review.

public class CashTranEntry_Extension : PXGraphExtension<CashTranEntry>
{
    protected virtual void CATran_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
    {
        var row = (CATran)e.Row;
        if (row?.TranType == CATranType.Disbursement && row.TranAmt > 10000m && row.Released != true)
            cache.RaiseExceptionHandling<CATran.hold>(row, true,
                new PXSetPropertyException("Disbursements over $10,000 require secondary approval.", PXErrorLevel.Warning));
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field (an internal category code separate from the standard transaction type, for instance) is a routine DAC extension on CATran. Because this screen is also where bank feed/reconciliation imports frequently land, any custom field meant to support matching logic should be populated by the import process itself, not left for manual entry after the fact.

Common validation and event-handler use cases

Beyond approval thresholds and auto-categorization: validating that transfers between two cash accounts always create balanced offsetting entries rather than a single one-sided row, blocking entries dated into a closed financial period the same way GL does, and flagging transactions that don't match any imported bank statement line within a reconciliation window for manual review.

Gotchas

A transfer between two cash accounts is really two linked CATran rows, not one — code that queries CATran for "all activity on this account" without understanding the transfer pairing can double-count or misrepresent transfers as external cash movement. Reconciliation status lives on a separate structure tied to bank statement import, not as a simple flag on CATran itself, so a customization checking "is this reconciled" needs to look at the right place rather than assuming a status field on the transaction. And released cash transactions post to GL the same as any other module — reversing one after release follows the same correction pattern as AR/AP documents, not a simple delete.

Wrapping up

Cash Transactions is the catch-all for cash movement that doesn't belong to a customer or vendor document, and its customizations are most valuable when they add the control this "residual" category often lacks — approval thresholds, categorization, and honest reconciliation status rather than assuming it's the complete cash ledger.