Transactions

Any place in Nimble AMS where there is an accounting impact, you will find transaction records. The transactions can result from the manual actions entered by staff in Staff View or by constituents in Community Hub—such as submitting an order, or through automated and scheduled processes—such as the recognition of membership deferred revenue. In every case, the creation of the transactions is done automatically by Nimble AMS; staff and constituents do not create them directly. To further safeguard your financial audit trail, transactions cannot be edited or deleted by staff or constituent actions. Common actions such as cancelling or modifying orders create the necessary reversing transactions automatically.

The transaction records hold the accounting details, such as the Batch, Bill To, Product Code, GL Account, Amount, Date, and more, and they are the source of the exports to your general ledger (GL) system.

Actions that Create Transactions

In Nimble AMS, transaction records follow generally accepted accounting principles of two–sided entries of debits and credits. When any of these actions occur, transactions are created :

• A new order is submitted and the order has at least one order item line with an Amount greater than zero. 
• An existing order is changed or cancelled, in full or in part, and the change(s) have a financial impact—for example, an order item line has a changed price or quantity. 
• A payment or a refund is processed on an existing order. 
• A prepayment or a refund of a prepayment is entered. 
• Recurring memberships on the date that they automatically renew (assuming they are not complimentary) and, if auto pay is in use, on the date when they are paid. 
• Deferred revenue is recognized during a nightly scheduled job. 

Key Fields on Transaction Records

These are key fields on transactions that may be useful for your analytics. 

• Bill To—the account with the primary financial responsibility for the transaction. 
• Customer—the account that is the "ship to" for the transaction. If for an event registration, this will be the attendee. 
• Amount—the transaction's amount. 
• Batch—the account that the transaction is part of.
• Category—possible values are: Debit or Credit.
• Date—the date from the transaction's batch. 
• GL Account—the GL account that is used for the GL export. If Type is AR, the order type's AR account is used. If Type is Income, the GL account of the order item line's product will be used. If the Type is Liability, the GL account that is the prepayment payable GL account is used. If the Type is Payment, the prepayment payable GL account is used. IfType is Payment, the GL account of the payment's bank account is used. 
• Order—the order that generated the transaction. 
• Order Item—the order item that generated the transaction. 
• Order Item Line—the order item line that generated the transaction. 
• Order Type—possible values are: New or Adjustment. 
  
• Payment Line—the payment line that generated the transaction. 
• Product Code—depending upon the Type, this field displays the name of product, bank account name (or credit card issuer, if applicable) or order type.
  
• Reference Group—is a unique number used on the set of transaction records that make up one accounting entry. 
  
• Reference Number—a unique number used for each transaction record within one accounting entry. 
  
• Source—identifies where the transaction originated. The value Salesforce means the transaction originated in Nimble AMS. The value Community Hub means the transaction originated in Staff View. 
• Type—possible values are: AR, Income, Liability, and Payment.
  

Things to Keep in Mind

• Nimble AMS does not create transactions for zero amounts. For example, an order for a merchandise item that is complimentary to members has no transactions. 
• Cash billing does not create financial transactions. Cash billing creates carts, which have no financial impact until they are paid and are converted to orders.