The field-by-field schema for all eleven FlexFactor CSV reports. Each report lists every column with its data type, business meaning, a sample value, and a reconciliation note, followed by the calculation formulas and the reconciliation workflow for that report. For a fast overview, use the Report Catalog; for shared data types and enumerations, see Data Formats & Enumerations.

Each field is documented with:

• Field Name — the exact CSV column header.
• Data Type — format and validation rules (see Data Formats & Enumerations for patterns).
• Description — business meaning and usage.
• Sample Value — an illustrative example. All sample values are fictitious.
• Reconciliation Notes — how to use the field when matching against your own systems.

Amounts are fixed-decimal strings with two places; negative values indicate reductions (refunds, fees, chargebacks, reserve holds). Timestamps are ISO 8601 UTC.

---

Report 1: Activity Detail

Report name: activity-detail
Use case: transaction-level detail for all merchant activity
Reconciliation use: match individual transactions against your order systems

Total columns: 14

🚧

Format exceptions in this report. EventTimestamp uses MM/DD/YYYY HH:MM:SS (values are UTC even though no timezone suffix is present) rather than ISO 8601, and amounts may omit trailing zeros (100, 45.7) rather than always carrying two decimal places. Parse both accordingly.

📘

Population: activity-detail carries processed transactions only (sales, returns, voids). Declined and failed authorization attempts never appear in this or any other report.

Reconciliation workflow

1. Import the CSV and parse EventTimestamp into your reporting timezone.
2. Join on ExternalId to match your orders.
3. Sum Amount where OrderState = 'completed' for revenue.
4. Sum Amount where TransactionType = 'Return' for refunds.
5. Verify card data (Bin / Last4) matches expected payment methods.

---

Report 2: Activity Summary

Report name: activity-summary
Use case: aggregated activity metrics by merchant for performance analysis
Reconciliation use: high-level revenue and fee verification by merchant and period

Total columns: 14

Formula

Expected Net Revenue = TotalProcessedAmount - ProcessingFees - ReturnsAmount - ChargebacksAmount

📘

TotalProcessedAmount sums completed orders only — refunds sit in ReturnsAmount, not netted into the gross. All reduction columns (ProcessingFees, ReturnsAmount, ChargebacksAmount) are positive magnitudes; subtract them as shown.

Reconciliation workflow

1. Verify From and To match your reporting period.
2. Compare TotalProcessedAmount to your sales ledger.
3. Verify ProcessingFees match fee invoices.
4. Reconcile NetAmount to expected deposits.
5. Cross-check OrderCount with transaction logs.

---

Report 3: Activity Exceptions

Report name: activity-exceptions
Use case: track refunds, chargebacks, voids, and credits
Reconciliation use: exception tracking and dispute management

Total columns: 13

Exception types

• refunded — customer refund processed (including RDR auto-refunds — an RDR appears here as a refund and in dispute-detail as a Kind = RDR row; count the financial impact once, from this report)
• disputed — chargeback or dispute filed
• voided — transaction cancelled before settlement

Reconciliation workflow

1. Match ExternalId to original orders.
2. Verify Amount matches refund/chargeback records.
3. Classify by ExceptionType for accounting entries.
4. Update order status based on OrderState.
5. Review ExceptionReason for pattern analysis.

---

Report 4: Settlement Summary

Report name: settlement-summary
Use case: settlement-batch summaries for payout reconciliation
Reconciliation use: match settlement batches to bank deposits

Total columns: 23

📘

All reduction columns are positive magnitudes — subtract them per the formula. ReserveUtilizationAmount covers losses other than this batch's own chargebacks (already in ChargebacksAmount), so both appearing in one batch is not double-counting.

Formula

SettlementAmount = TotalProcessedAmount
                   - ProcessingFees
                   - ReturnsAmount
                   - ChargebacksAmount
                   - ReserveAmount
                   + ReserveReleaseAmount
                   - ReserveUtilizationAmount
                   + Adjustments

Reconciliation workflow

1. Match SettlementDate to the bank-deposit date.
2. Verify SettlementAmount matches the bank deposit.
3. Reconcile BatchId or CED with internal settlement records.
4. Review reserve changes (ReserveAmount, ReserveReleaseAmount, ReserveUtilizationAmount).
5. Account for Adjustments separately.

---

Report 5: Settlement Detail

Report name: settlement-detail
Use case: transaction-level detail within settlements
Reconciliation use: detailed breakdown of what is included in each settlement

Total columns: 15

Formula

DepositAmount = ConsumerAmount - ConsumerFee - FlexFactorFee

For returns, ConsumerAmount is negative, so DepositAmount is also negative.

Reconciliation workflow

1. Group by settlement batch (join with Settlement Summary if needed).
2. Sum DepositAmount to verify the batch total.
3. Match ExternalId to your order records.
4. Verify FlexFactorFee matches your fee agreement.
5. Account for returns separately (negative ConsumerAmount).

---

Report 6: Settlement Exceptions

Report name: settlement-exceptions
Use case: track failed or rejected settlement batches
Reconciliation use: identify and resolve settlement failures

Total columns: 10

Exception types

• FAILED — settlement-batch processing failed
• ERROR — system error during settlement
• REJECTED — settlement rejected by the bank/processor

Reconciliation workflow

1. Identify missing settlements by comparing expected vs. actual deposits.
2. Match BatchId to expected settlement batches.
3. Review ExceptionReason to determine remediation.
4. Track resolution of failed settlements.
5. Re-reconcile once failures are resolved.

📘

Retries keep the same BatchId. When a failed batch is retried and succeeds, the same BatchId appears in settlement-summary with the payout completed — match on BatchId and there is no double-count risk.

---

Report 7: Fees

Report name: fees
Use case: detailed fee breakdown per transaction
Reconciliation use: fee expense accounting and verification

Total columns: 10

Fee types

• FlexFee — standard processing fee (charged on orders)
• FlexReturnFee — fee for processing a refund/return (including RDR auto-refunds)
• FlexChargebackFee — fee for processing a chargeback/dispute

📘

This report is the fee statement of record. Fees are net-settled — deducted from payouts, never invoiced separately — and these three types cover all fee expense. The finer fee labels in the disbursement-fee report (Processing Fee, Refund Fee, Dispute Fee, ...) are subtypes of the same fees, not additional charges.

Reconciliation workflow

1. Sum FeeAmount by FeeType for expense classification.
2. Verify total fees match settlement deductions.
3. Calculate the effective fee rate: FeeAmount / OrderAmount.
4. Match ExternalId to transaction records.
5. Reconcile with fee invoices or agreements.

---

Report 8: Monthly Settlement Summary

Report name: monthly-settlement-summary
Use case: monthly aggregated settlement overview
Reconciliation use: monthly financial close and performance analysis

Total columns: 11

Formula

NetSettlement = TotalSettledAmount - TotalFees

Reconciliation workflow

1. Verify Month / Year match your accounting period. The month boundary is the UTC calendar month — if your ledger runs on a local timezone or a non-calendar fiscal period, account for the offset.
2. Sum all daily settlements and compare with TotalSettledAmount.
3. Verify NetSettlement matches total monthly deposits.
4. Compare OrderCount with transaction logs.
5. Use for monthly financial reporting and variance analysis.

---

Report 9: Monthly Settlement Detail

Report name: monthly-settlement-detail
Use case: detailed monthly settlement with batch-level breakdown
Reconciliation use: monthly settlement audit and batch-by-batch verification

This report is structurally identical to Settlement Summary (23 fields) but filtered to a specific month, and it supports month-to-date reporting.

Total columns: 23

Reconciliation workflow

1. Filter by Month (implicit in report generation).
2. Sum SettlementAmount to verify the monthly total.
3. Match individual batches to bank deposits.
4. Track month-to-date progress if the report is run mid-month.
5. Cross-reference with Monthly Settlement Summary totals.

---

Report 10: Dispute Detail

Report name: dispute-detail
Use case: chargeback and dispute tracking
Reconciliation use: dispute liability and resolution tracking
Format: multi-section CSV, Braintree-compatible

Each row begins with a record-type prefix identifying its section:

• RH — report header (metadata about the report)
• RD — report detail (individual dispute records)
• RF — report footer (record counts)

The prefix is a section identifier, not a counted field; the field counts below exclude it. Total documented fields: 53 (RH 4 + RD 46 + RF 3).

📘

Braintree-compatible. This report mirrors the Braintree Dispute Detail export. Many RD columns exist for format compatibility only and are not populated by FlexFactor — they are marked "not tracked; always empty" below. Because the Outcome, Status, and Amount Won columns are always empty, dispute win/loss resolution cannot be read from this report; track it in your own dispute system.

📘

Each section begins with a header row. The first row for each prefix carries the section's column names, followed by the data rows — skip the header rows when loading data. Two RD header names contain a double space — Postalcode Response Code and Chargeback Protection — so match headers exactly rather than assuming single spacing.

🚧

PII note. Unlike the flat CSV reports, the RD section carries customer PII — Customer Name and Customer Email. The card number is fully masked (****); no full PAN, CVV, or expiry is present. Handle this report as containing customer PII even though it stays outside PCI cardholder-data scope. Sample values below are fictitious.

Section RH — Report Header

Total RH fields: 4

Section RD — Report Detail (dispute records)

46 fields per dispute record. Fields marked "not tracked; always empty" are present for Braintree format compatibility but are not populated by FlexFactor.

Total RD fields: 46

Kind field values (RD field 11)

The Kind field carries the dispute stage. Ten values are defined:

Section RF — Report Footer

Total RF fields: 3

Reconciliation workflow

1. Parse the multi-section format by line prefix (RH, RD, RF).
2. Verify RF Total Records matches the actual RD row count.
3. Match Dispute ID, Record ID (transaction), or Order ID to your systems.
4. Group by Kind to separate dispute stages (RDR vs. chargeback vs. pre-dispute warnings vs. network inquiries such as Order Insight and Consumer Clarity).
5. Monitor Reply Before Date for time-sensitive responses.
6. Track win/loss in your own dispute system — the report Outcome, Status, and Amount Won columns are always empty.
7. Cross-reference with the activity-exceptions report for financial impact.

---

Report 11: Disbursement Fee

Report name: disbursement-fee
Use case: Braintree-compatible disbursement and fee detail
Reconciliation use: comprehensive settlement and fee reconciliation
Format: multi-section CSV, Braintree-compatible

• RH — report header (report metadata)
• RS — report summary (merchant-level aggregation)
• RD — report detail (transaction-level detail)
• RF — report footer (record counts)

The prefix is a section identifier, not a counted field; the field counts below exclude it. Total documented fields: 81 (RH 4 + RS 14 + RD 60 + RF 3).

📘

Braintree-compatible. This report mirrors the Braintree disbursement/fee export.

📘

Each section begins with a header row. The first row for each prefix carries the section's column names (e.g. RD,Record ID,Merchant Account ID,...) followed by the data rows. Skip the header rows when loading data — see the layout example in Data Formats & Enumerations.

Section RH — Report Header

Total RH fields: 4

Section RS — Report Summary (merchant aggregation)

Total RS fields: 14

Formula

NetDisbursedAmount = Sales + Refunds + Disputes + Other + NetFees

Refunds, Disputes, and NetFees are negative values.

Section RD — Report Detail (transaction-level)

The RD section carries 60 fields per row. Rows are signed: sale rows are positive; refund, dispute, and fee rows are negative. Fields marked (empty in current exports) exist for Braintree format compatibility and are not populated today.

Total RD fields: 60

📘

Fees are their own rows. Each fee appears as a separate RD row (Record Type = Fees) with a negative amount, tied to its transaction via Order ID — the per-row Total Gross Fees / Total Net Fees columns stay 0.00. The RS Net Fees aggregate is the sum of the Fees rows. This enables per-order fee reconciliation directly from the RD section.

📘

Note on Disbursement Date (field 9): populated, but it currently carries the same value as Settlement Date rather than a distinct disbursement timestamp. Do not rely on it to distinguish disbursement timing from settlement timing.

RecordType → RecordSubtype mapping

The RD Record Type / Record Subtype pair classifies each row:

Section RF — Report Footer

Total RF fields: 3

Reconciliation workflow

1. Parse the multi-section CSV format by line prefix (RH, RS, RD, RF).
2. Verify RF Total records matches the actual RD row count.
3. For each RS record, verify the disbursement calculation.
4. Match Merchant Account ID to your merchant master.
5. Reconcile RS Net Disbursed Amount to bank deposits.
6. Match Transfer ID(s) to actual bank-transfer references.
7. Drill into RD records for transaction-level detail; use the RecordType → RecordSubtype mapping to classify each row.
8. Reconcile RS Sales with the activity-summary totals.