Journal Entry Item

Overview

Journal Entry Items are the individual line items that make up a journal entry. While the journal entry represents a complete accounting transaction, each item represents one side of that transaction - a specific amount being debited or credited to a specific account.

Each item specifies which general ledger account is affected and whether it's a debit or credit. The amount shows how much the account changes. Together, all the items in a journal entry must balance - total debits must equal total credits. This is the fundamental rule of double-entry accounting, and the system enforces it.

Line items often include descriptions that explain their purpose within the journal entry. While the journal entry as a whole has a description, line-level descriptions can provide additional context about each specific account being affected. This is helpful when reviewing entries later or during audits.

In complex journal entries, you might have many line items affecting different accounts. For example, a month-end closing entry might adjust multiple revenue accounts, expense accounts, and balance sheet accounts in a single transaction. Each adjustment is captured as a separate journal entry item, giving you line-by-line detail about what changed and why.

The relationship between journal entries and their items is one-to-many - each journal entry contains multiple items. When you query a journal entry through the GraphQL API, you'll typically include the items to see the complete picture. This lets you understand not just that an entry was made, but exactly which accounts were affected and by how much.

Journal entry items are created when the journal entry is created and can be modified while the entry is in draft status. Once the journal entry is posted, the items become locked and create the actual general ledger entries. This ensures that posted accounting transactions are immutable, maintaining the integrity of your financial records.

GraphQL API

The journalEntryItem collection provides access to journalEntryItem data via the GraphQL API. All queries use the Relay connection specification with cursor-based pagination.

Query Name: journalEntryItemViewConnection

Available Features:

• Cursor-based pagination (first/last/after/before)
• 3 relations to other collections

Query Examples

Basic Query

The journalEntryItem collection is accessed via the journalEntryItemViewConnection query, which returns a Relay-style connection with pagination support.

query {
  journalEntryItemViewConnection(first: 10) {
    edges {
      node {
        accountingClass
        amount
        effectiveDateAvgCost
        expectedAverageCost
        itemIndex
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Pagination

Use cursor-based pagination to retrieve large datasets:

# First page
query {
  journalEntryItemViewConnection(first: 50) {
    edges {
      node { accountingClass }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

# Subsequent pages
query {
  journalEntryItemViewConnection(first: 50, after: "cursor-from-previous-page") {
    edges {
      node { accountingClass }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Relations

Query related data (see Relations section for all available relations):

query {
  journalEntryItemViewConnection(first: 10) {
    edges {
      node {
        accountingClass
        creditAccount {
          name
          glAccountUrl
        }
      }
    }
  }
}

Summary and Aggregation

This collection supports data aggregation and dimensional analysis through the summary field. You can calculate metrics (like totals, averages, counts) and group them by dimensions (like category, date, status).

For a comprehensive guide to using aggregations, see the Aggregation Concept Guide.

Query Structure

journalEntryItemViewConnection(filters...) {
  summary {
    errorCode
    errorMessage
    groupBy {
      # Group by dimensions (see table below)
    }
    metrics {
      # Calculated metrics (see table below)
    }
  }
}

Available Metrics

This collection provides 25 metrics that can be aggregated:

Common Parameters:

• operator - Aggregation function: sum, mean, min, max
• transform - Mathematical transformation: abs
• dateRange - Filter to specific date range
• facilityUrlList - Filter to specific facilities

GroupBy Dimensions

Group metrics by these dimensions:

All dimensions accept a formatter parameter: "html", "none", "abbreviated", "blank-zero".

Examples

Example 1: Basic Aggregation

Calculate metrics for journalEntryItem:

query {
  journalEntryItemViewConnection(first: 1) {
    summary {
      errorCode
      errorMessage
      groupBy {
        # Add dimensions here
      }
      metrics {
        totalCount: count
      }
    }
  }
}

Fields

This collection has 9 fields:

• 9 simple fields
• 0 enum fields (with predefined values)
• 0 parameterized fields (accept query options)

Note on Field Formatting: All scalar fields support the formatter argument to control output format. Available options: "html", "none", "abbreviated", "blank-zero". Some fields have a default formatter (shown below). See the Formatting guide for details.

Note on Sorting: Field sortability may vary depending on the UI context and query parameters used. Some parameter options explicitly disable sorting (marked with ⚠️ not sortable).

Simple Fields

These fields return values directly without additional options.

accountingClass

An optional classification value used to categorize and group journal entry items for accounting purposes. This field stores a text value that represents a configured accounting dimension such as a sales source (e.g., "Amazon", "Shipstation"), product category, or custom field value. The accounting class is automatically computed based on the journal entry type and the system's accounting class configuration, which determines which business dimension (sales source, product category, or custom field) should be used for classification. When consolidating transactions, the system uses the accounting class along with the credit and debit account URLs to group related journal entry items together, ensuring that entries with different classifications remain separate even if they share the same GL accounts. This enables more granular financial reporting and analysis by business segment, sales channel, or other custom dimensions configured for the account.

Label: Accounting class
Sortable: No

amount

The monetary value being transferred between the debit and credit accounts for this journal entry item. This field is required for standard journal entries (JOURNAL_ENTRY type) but is not used for average cost change entries (AVERAGE_COST_CHANGE type), which track cost adjustments rather than monetary transfers. The amount must be a valid currency value with precision to two decimal places (X.XX). Values are automatically rounded to currency precision during import, and negative amounts are permitted to represent reversals or corrections. For reporting purposes, the amount can be shown as either a debit amount (positive) or credit amount (negative) depending on the accounting perspective.

Label: Amount
Sortable: No

creditAccount

The general ledger account that receives the credit side of the accounting entry for this journal entry item. In double-entry accounting, every transaction affects at least two accounts - one debited and one credited. This field specifies which account is credited for this particular item.

Journal entries can have multiple items, where each item may credit a different account or have only a credit or only a debit. For example, in a transfer transaction between accounts, one item might specify both creditAccount and debitAccount fields, while in multi-line entries, different items might credit or debit different accounts to balance the overall transaction.

This field relates to the generalLedgerAccount collection and can be null when an item only has a debit side or when account information is not specified. The field is commonly used alongside debitAccount to create balanced accounting entries that properly record financial transactions in accordance with double-entry bookkeeping principles.

Label: Credit account
Sortable: No

debitAccount

The general ledger account to be debited in a journal entry line item. In double-entry accounting, each journal entry item specifies either a debit account or a credit account (or both for transfer entries), representing one side of the accounting equation. For standard journal entries, the debit account receives the debit amount while the corresponding credit account is specified in a separate line item. This field is required when importing journal entry items unless the entry type is AVERAGE_COST_CHANGE, which uses product and expected average cost instead. The system validates that the account reference is valid and can filter, group, and report on journal entry items by their debit accounts. When set to an empty or invalid value, the field is cleared to null.

Label: Debit account
Sortable: No

effectiveDateAvgCost

The product's average cost as of the journal entry's effective date. This field represents a calculated, read-only snapshot of what the product's average cost was at the specific point in time when the journal entry takes effect. For journal entries with status JOURNAL_COMPLETED, this shows the average cost immediately before the journal entry was completed. For entries with status JOURNAL_CREATED (draft entries), this shows the average cost at the journal entry's record date. This field is particularly useful when recording average cost changes, as it allows users to see the current average cost before applying the new expected average cost. The value is computed dynamically based on the product's cost history and may vary depending on when transactions were received and completed. This field returns null when the product or journal entry information is unavailable.

Label: Effective date avg cost
Sortable: No

expectedAverageCost

The target average cost value for a product when recording an average cost change. This field is used exclusively in journal entries with type AVERAGE_COST_CHANGE to manually adjust a product's average cost. When creating an average cost change entry, this field must contain a valid finite number representing the desired new average cost for the specified product. The system validates that each product appears only once per journal entry and requires both a product reference and this expected cost value for the entry to be valid. This field is formatted as a currency price and is typically displayed right-aligned in UI tables.

Label: Expected avg cost
Sortable: No

itemIndex

The sequential position of this item within the journal entry's item list, using 1-based numbering (the first item is 1, the second is 2, etc.). This field represents the display order of line items in a journal entry and is used throughout the system to identify and reference specific items when performing lookups, calculations, and data operations. For example, when allocating costs or matching items across related documents, the itemIndex serves as a positional identifier within the parent journal entry. The value is automatically assigned based on the item's position in the journalEntryItemList array, where itemIndex equals the array index plus one. This field is particularly important in pivot table operations and data import/export workflows where maintaining the correct item sequence is essential for proper accounting and reporting.

Label: Item index
Sortable: No

notes

A free-form text field for adding descriptive comments or explanations to individual journal entry line items. This field allows users to provide context about specific accounting entries, such as describing the nature of a transaction (e.g., "cost of goods", "transfer", "income coming in") or providing additional details that help explain why a particular debit or credit was recorded. The item notes are distinct from the journal entry-level notes field, allowing more granular documentation at the line item level. This field is optional and can be left blank, and is available when creating or importing both regular journal entries and average cost change entries.

Label: Item notes
Sortable: No

resultingAvgCost

The product's average cost after the journal entry takes effect. This read-only calculated field shows what the average cost will be (or is, if completed) once the journal entry is processed. For journal entries with status JOURNAL_CREATED (draft entries), if an expected average cost has been specified, this field displays that value as the projected resulting cost. For entries with status JOURNAL_COMPLETED, this shows the actual average cost at the time the journal entry was completed. For JOURNAL_CANCELLED entries, this shows the average cost at the journal entry's record date. This field is particularly useful in average cost change journal entries, allowing users to preview the impact of their changes before posting. The value is computed dynamically based on journal entry status, expected average cost, and the product's cost history. When the expected average cost is not a finite number or context calculation is unavailable, this field returns null.

Label: Resulting avg cost
Sortable: No

Relations

creditAccount

• Related Collection: generalLedgerAccount
• Label: Credit account

TODO: Add relation description

debitAccount

• Related Collection: generalLedgerAccount
• Label: Debit account

TODO: Add relation description

product

• Related Collection: product
• Label: Product

TODO: Add relation description

Filters

No filters available.