> For the complete documentation index, see [llms.txt](https://docs.omni.integratedcommerce.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omni.integratedcommerce.io/glossary/settlement-and-fees.md). # Settlement and fees Standalone definitions of settlements, settled transactions, fee charges, funding models, and reconciliation terms. These terms describe the records used to connect a merchant's payment activity with bank deposits and processing costs. They use the meanings in the settlement reporting API, which is currently in beta. ## ACH Gross An ACH funding arrangement in which processing fees are billed separately from the merchant's deposit. It is represented by `type: Ach` and `fundingType: Gross`. Settled line amounts exclude those separately billed fees, and their sum equals the settlement amount. A failed payout with no disbursement has a zero line amount. See [ACH reconciliation](/settlement-reporting/settlements.md#how-far-the-lines-reconcile-to-the-deposit-total). ## ACH Net An ACH funding arrangement in which applicable fees are withheld from the merchant's deposit. It is represented by `type: Ach` and `fundingType: Net`. Each settled line's amount reflects any fees withheld from that line; deposit-level fees can further reduce the settlement total. A failed payout can produce a negative line amount equal to the fee for the attempt. ## Adjustment A change to the amount being deposited that is not another sale, such as a reserve hold or transfer. Adjustments help explain why a processor-reported deposit can differ from the total of its transaction lines. Some affect the deposit total without appearing as public transaction lines or posted fee charges. See [Reconciliation limits](/settlement-reporting/settlements.md#how-far-the-lines-reconcile-to-the-deposit-total). ## Batch A group of transactions collected by the processor for processing or settlement. A settled card line's `batchId` identifies its processor batch. One merchant deposit can include transactions from several batches, so the batch identifier belongs to each line rather than to the settlement as a whole. ## Billing period and statement period The span of activity covered by a bill or statement. A fee charge can expose `periodStart` and `periodEnd` to identify the activity it covers. These dates can differ from `chargeDate`, which identifies when the fee is charged. Reconcile statement fees for the same merchant, payment rail, and statement period. ## Card Gross A card funding arrangement in which interchange and discount fees are billed separately instead of being deducted from the deposit. It is represented by `type: Card` and `fundingType: Gross`. Reserve holds and transfers can still change the deposit, while card line amounts remain the full settled transaction amounts. "Gross" does not specify when the fees are billed. See [Card funding examples](/settlement-reporting/settlements.md#card-net-and-card-gross-example). ## Card Net A card funding arrangement in which interchange and discount fees are deducted before payment proceeds are deposited to the merchant. It is represented by `type: Card` and `fundingType: Net`. Card line amounts remain the full settled transaction amounts; the fee deductions and reserve adjustments apply to the deposit total. See [Card funding examples](/settlement-reporting/settlements.md#card-net-and-card-gross-example). ## Charge date The date a fee is charged to the merchant, exposed as `chargeDate` and used to select records from `GET /fee-charges`. For transaction and settlement fees assessed daily, daily billing uses the settlement date and monthly billing uses the first of the following month. The charge date can therefore differ from the date the underlying payment was processed or settled. ## Daily settlement fees Charges identified from daily settlement activity. The category describes what the merchant is paying for; the funding and billing terms determine how and when it is collected. | Category | Definition | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `DailyDiscountFee` | The card processor's charge for handling the day's settled card payments. It is reported for the settlement as a whole and deducted from a Card Net deposit. | | `DailyInterchangeFee` | The card-processing cost associated with the issuer's part of the payment, reported for the settlement day. It is deducted from a Card Net deposit. | | `TransactionFee` | A processing cost assessed on an individual settled transaction, such as an ACH transaction's processing fee. | | `ReturnFee` | A charge for a payout attempt that could not deliver funds to the merchant's bank account. It can be owed even though nothing was disbursed. | | `PerSettlementFee` | A flat charge applied once to a merchant deposit, independent of the number or value of its transaction lines. | The reported charge supplies the amount; these categories do not define a rate or calculation formula. See [Transaction and settlement fees](/settlement-reporting/fee-charges.md#transaction-and-settlement-fees). ## Deposit amount and line amount A deposit amount is the processor-reported total for a settlement, exposed as the settlement's `amount`. A line amount is the contribution attributed to one settled transaction, exposed as that line's `amount`. Card lines are before deposit-level fees and reserves under both funding types. ACH Net lines reflect their own withheld fees. Read the settlement `type` and `fundingType` to interpret either amount. ## Deposit, disbursement, and payout A deposit is a transfer of payment proceeds into the merchant's bank account, represented by a settlement record. Disbursement and payout describe the act of sending those proceeds. A payout attempt can fail, in which case no deposit occurs for that attempted transfer even though a reporting line or fee can be recorded. ## Fee breakdown An optional description of the components that make up a fee charge, exposed as `feeBreakdown`. Only components supplied by the source report are present: | Field | Definition | | ---------------- | ----------------------------------------------------------------------------------- | | `discountFee` | The processing or discount-fee component. | | `originationFee` | The component charged for originating an ACH transaction. | | `returnFee` | The component charged for an ACH transaction returned or reversed after settlement. | | `interchangeFee` | The card interchange-fee component. | | `otherFee` | A fee component without a more specific field in this breakdown. | The components explain the fee charge's amount; they are not additional charges. Read `returnFee` as a cost of a returned or reversed ACH transaction. A settled line's `transactionType: Return` has a separate, specific meaning: a failed payout to the merchant. ## Fee category The classification identifying the kind of merchant cost represented by a fee charge, exposed as `category`. It can be a broad group such as `Equipment`, a daily settlement fee such as `TransactionFee`, or a specific statement fee name. The field is an open set of strings, so integrations must preserve and handle unfamiliar values. The `description` provides the reported fee wording. ## Fee charge A record of an individual cost billed to a merchant for payment processing or related account services. It states the amount, currency, category, charge date, and description of that cost. A charge can be withheld from a deposit or billed separately; when applicable, it links to a settlement and a settled transaction. The API identifies it with an `mfc_` ID and lists it through `GET /fee-charges`. See [Fee charges](/settlement-reporting/fee-charges.md). ## Fee source The classification describing how a fee is reported and billed, exposed as `source`. It helps separate charges accounted for in daily settlement reporting from those assigned to monthly billing: | Value | Definition | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | `SettlementLinked` | A fee from daily settlement activity charged on its assessment date under daily billing. | | `StatementOnly` | A fee billed through a monthly statement or invoice, including transaction and settlement fees scheduled for monthly billing. | A `StatementOnly` charge can retain a `settlementId`. That link identifies its origin and does not, by itself, mean the fee reduced that deposit. See [Fee sources](/settlement-reporting/fee-charges.md#source-where-the-fee-came-from). ## Fee status The classification describing whether a recorded fee entry was charged to the merchant, exposed as `status`. `Posted` identifies a charged entry and is the only status returned by `GET /fee-charges`. `Held` identifies an entry held rather than posted as a charge, and `Reversed` identifies an entry backed out later. Held and reversed entries are excluded from this endpoint. ## Funding type The merchant funding arrangement that determines how processing fees affect a deposit. `fundingType: Net` means applicable fees are withheld from the deposit; `Gross` means fees are billed separately. Read it with settlement `type`, because card and ACH line amounts follow different rules. Funding type does not determine the fee billing schedule. See [Settlement type and funding type](/settlement-reporting/settlements.md#settlement-type-and-funding-type). ## Gateway transaction ID The identifier assigned by the downstream gateway to the payment activity reported on a settled line, exposed as `gatewayTransactionId`. It helps connect source settlement data with payment records. It is separate from the Fiska `transactionId`, which uses the `trx_` prefix and can be absent on an unmatched line. ## General fee categories Broad groups used to classify the services or activities for which the merchant is billed: | Category | Definition | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `MonthlyService` | Fees for maintaining the merchant account and related payment services, such as statements, reporting, and gateway services. | | `PciCompliance` | Fees related to Payment Card Industry (PCI) compliance, including compliance services and non-compliance assessments. | | `OneTimeSetup` | One-time fees for setting up a service, such as an account, gateway, or wireless connection. | | `NetworkAssessment` | Card-network charges passed through to the merchant, such as registration or network participation fees. | | `Equipment` | Fees for payment terminals and related hardware, including charges for equipment that was not returned. | | `Other` | Fees with no more specific classification. Read `description` for the reported fee wording. | See [Fee categories](/settlement-reporting/fee-charges.md#general-fee-categories) for their place in fee reporting. ## Interchange and passthrough Card-processing costs attributed to interchange and other charges passed through on a statement without individual names. The API's `InterchangeAndPassthrough` fee is a calculated remainder: the statement's total deducted fees minus all named fee lines. It appears as `StatementOnly` and lets the fee-charge list account for the complete deducted total. See [Derived fees](/settlement-reporting/fee-charges.md#derived). ## Match status The result of trying to associate a processor-reported settled line with a Fiska transaction, exposed as `matchStatus`: | Value | Definition | | ----------------- | ------------------------------------------------------------------------------------ | | `Matched` | The line was automatically associated with a Fiska transaction. | | `ManuallyMatched` | The line was associated with a Fiska transaction through manual reconciliation. | | `Unmatched` | No Fiska transaction has been identified for the line, so `transactionId` is absent. | An unmatched line still belongs to the settlement and contributes its reported amount. See [Match status](/settlement-reporting/settlements.md#match-status). ## netAmount The deprecated reporting field name replaced by `amount`. Where still returned, it mirrors `amount` exactly. Its name does not guarantee an amount after fees: settlement type and funding type determine what the amount includes. See [Deprecated: netAmount](/settlement-reporting/reporting.md#deprecated-netamount). ## Reconciliation The process of connecting payment records, settled transaction lines, fee charges, and bank deposits so their amounts and identifiers explain the same activity. In this API, it includes matching a settled line's `transactionId` to a Fiska transaction and checking deposits using the applicable funding rules. Missing card batch data or reserve movements can prevent public line items alone from reproducing a deposit total. See [The reporting model](/settlement-reporting/reporting.md). ## Reserve hold and reserve transfer A reserve hold is money retained from merchant proceeds in a reserve balance. A reserve transfer moves money into or out of that balance. These movements can change Card Net and Card Gross deposits, but they are not charges for a service. The public API does not expose them as transaction lines or posted fee charges. See [Card reconciliation](/settlement-reporting/settlements.md#how-far-the-lines-reconcile-to-the-deposit-total). ## Return In settled transaction reporting, a `Return` is a payout attempt that failed to deliver funds to the merchant, for example because the receiving bank account was closed or invalid. The line records the failed attempt and any resulting fee. Its amount can be negative under ACH Net or zero under ACH Gross. This reporting value describes a failed disbursement; a `Refund` describes money being returned to a payer after a payment. ## Settled transaction A processor-reported line showing how payment or dispute activity contributes to a merchant deposit. It records the activity's amount and processor identifiers, plus the Fiska transaction ID when a match is available. Card lines show full settled amounts before deposit-level fees and reserves; ACH lines reflect any fees withheld from that line. Read these records in a settlement's `lineItems` or through `GET /settlements/transactions`. See [Settled transactions](/settlement-reporting/settlements.md#settled-transactions). ## Settlement A record of a processor-reported transfer of payment proceeds to the merchant's bank account. It groups the transaction activity included in one deposit and states the deposit date, currency, total amount, payment rail, and funding type. Fees, refunds, and reserve movements can affect that total. The API identifies a settlement with an `stl_` ID and exposes its transaction lines through `GET /settlements/{settlementId}`. See [Settlements](/settlement-reporting/settlements.md). ## Settlement date and transaction date The settlement date is the date the deposit is reported as reaching the merchant's bank account. The transaction date is the date the underlying payment operation was processed, when available. Settlement list endpoints select records by settlement date, so they can include payments made on earlier dates. ## Settlement status The deposit's reporting state, exposed as settlement `status`. `Settled` means the deposit has been made to the merchant's bank account. `Adjusted` is a reserved value and is not currently returned. This field describes a deposit record rather than the processing lifecycle of a payment request. ## Settlement transaction type The activity represented by a settled line, exposed as `transactionType`. `Sale` records a sale, `Refund` records a refund or credit to the payer, `Capture` records settlement of an earlier authorization, and `Return` records a failed payout to the merchant. `Dispute` records a dispute debit, and `DisputeReversal` records funds returned to the merchant during a challenge. Both dispute types apply to all payment methods. See [Transaction type](/settlement-reporting/settlements.md#transaction-type) for the full definitions. ## Settlement type The payment rail from which a merchant deposit originated, exposed as `type: Card` or `Ach`. It is used with `fundingType` to interpret the deposit and transaction amounts. Card Net and Card Gross are combinations of these fields, not additional settlement type values. ## Signed amount An amount that can be positive, zero, or negative. Settlement deposits and transaction lines use signed amounts so refunds, fees, and adjustments can reduce totals. A negative settlement amount represents a net movement away from the merchant rather than an incoming deposit. See [Signed amounts](/settlement-reporting/reporting.md#signed-amounts). ## Statement fee A cost billed on the merchant's periodic statement or invoice, such as an account-service or equipment charge. A recognized fee can be reported under its specific name in `category`. The fee guide gives representative examples grouped by general category. Read the reported `description` when interpreting an individual charge. See [Statement fee examples](/settlement-reporting/fee-charges.md#fees-billed-on-a-monthly-statement-or-invoice). ## Withheld fee A fee collected by deducting it from payment proceeds before they reach the merchant. The fee is also listed as a fee-charge record for reporting. When a settlement or ACH line amount already reflects that deduction, subtracting the fee again understates the money received. ## Zero-movement line A settled transaction line for activity that disbursed no funds, commonly a failed payout recorded as `Return`. It remains part of the deposit's reported activity and can still carry a fee. Its amount is zero when fees are billed separately, or negative when its fee is withheld. See [Zero-movement lines](/settlement-reporting/reporting.md#zero-movement-lines). ## Related * [The reporting model](/settlement-reporting/reporting.md) - how the three resources relate * [Settlements](/settlement-reporting/settlements.md) - endpoint usage and reconciliation examples * [Fee charges](/settlement-reporting/fee-charges.md) - billing sources and fee categories * [Payments and transactions](/glossary/payments-and-transactions.md) - the original payment operations