Posted Transactions Overview

The Posted Transactions CSV report provides visibility into transactions as they appear on a client’s bank statement. This report is designed to support reconciliation and statement alignment and answers a different question than settlement‑based reports.

This guide explains what Posted Transactions represent, how they differ from Settled Transactions, and when clients should expect to receive them.

What Are Posted Transactions?

A posted transaction reflects the date on which a transaction appears on the client’s bank statement.

This differs from settlement, which reflects when a transaction reaches completion within Newline’s processing systems and underlying payment rails.

In many cases, settlement and posting occur on the same day — but they do not always align.

Why Posted ≠ Settled

Settlement and posting can differ due to banking and payment‑rail behavior.

Common examples include:

• Instant Payments (RTP / FedNow): Transactions may settle immediately on a weekend but post on the next business day.
• Same‑day ACH cutoffs: Transactions received late in processing windows may post later.
• Fees and interest: These may be back‑dated when posted by the bank.
• Manual entries: Transactions created or ingested later may post with earlier dates.

Because of these scenarios, settlement‑based reporting alone may not fully align with bank statements.

What the Posted Transactions Report Contains

The Posted Transactions CSV provides a statement‑aligned view of account activity, focused on when transactions are reflected by the bank rather than when they settle within Newline.

Included Data

The report includes transactions that posted to the account during the prior business banking day. Depending on account activity and configuration, this may include:

• Originated transactions
• Received transactions
• Batch‑level details, when applicable (for example, ACH batches)

Reporting Scope and Purpose

This report is delivered as a Prior Day CSV and is designed to support:

• Bank statement reconciliation
• Statement alignment
• Financial audit and review workflows

Field Overview (High Level)

The Posted Transactions CSV includes a subset of transaction and account fields required to support statement‑level reconciliation. Field population may vary by payment rail.

Core Field Categories

The report includes the following high‑level categories of data:

• Transaction identifiers
  Newline transaction IDs and external reference identifiers used to uniquely identify each transaction.

• Posted timestamp
  The date on which the transaction appears on the client’s bank statement. This may differ from the transaction’s settled date.

• Account information
  Identifiers linking each transaction to the posting account.

• Monetary amounts
  Posted debit or credit amounts associated with the transaction.

• Rail‑specific fields
  Optional attributes populated based on payment rail (for example, ACH batch details or wire metadata).

Not all fields populate for all transactions or rails.

Rail‑Specific Notes

Certain Posted Transactions fields populate differently depending on the underlying payment rail. These behaviors are expected and intentional.

ACH Transactions

• Received ACH entries may have a blank batch_id
  Batch identifiers are only populated when a batch is created or managed by Newline. Received ACH entries may not include batch‑level metadata.

• Posting may occur on a later business day than settlement due to bank processing windows or cutoffs.

Instant Payments (RTP / FedNow)

• Instant payments may settle immediately, including on weekends.
• Posting typically occurs on the next business day, resulting in settlement and posted dates that differ.

Wire Transactions

• Wire transactions may include additional metadata depending on timing and processing.
• Some wire attributes may be conditionally populated based on when posting occurs relative to settlement.

Because schema fields are shared across rails, some columns may appear blank even when included in the schema. This does not indicate an error.

When Posted Transactions Are Delivered

Posted Transactions follow standard Prior Day reporting behavior.

Delivery Timing

• File generation begins after banks complete end‑of‑day processing
• Files are delivered the following day, after posting is finalized
• Delivery occurs daily, including weekends and holidays

Non‑Business Days

On weekends and bank holidays, Posted Transactions reports frequently contain no rows because transaction posting does not occur on bank‑closed days.

Header‑Only Posted Transactions Files

Header‑only Posted Transactions files are expected and valid.

These files indicate:

• No transactions posted during the prior reporting period
• Successful file generation and delivery
• Normal system behavior—not a processing or delivery error

Clients should treat header‑only files as successful deliveries and continue standard ingestion workflows.

Availability and Rollout Status

The Posted Transactions report:

• Requires Prior Day reporting to be enabled
• Is currently available on a limited basis
• Is expected to become a standard offering following stabilization

Clients will be notified prior to the report being enabled for their program.

How Posted Transactions Fit with Other CSV Reports

Different CSV reports serve different operational and financial needs.

Clients commonly use:

• Settled Transactions for operations and monitoring
• Posted Transactions for finance, reconciliation, and accounting workflows

Reconciliation Guidance

The Posted Transactions CSV is designed specifically for statement‑based reconciliation and end‑of‑period financial close.

How to Use This Report for Reconciliation

Clients should use the Posted Transactions CSV to:

1. Identify transactions that posted to the bank statement during the prior business banking day.
2. Match posted transactions to bank statement line items using posted dates, amounts, and identifiers.
3. Reconcile posted transaction totals against closing balances generated through reconciliation logic.
4. Use settlement‑based reports separately for operational monitoring and lifecycle tracking.

Because posting may lag settlement, reconciliation workflows should rely on Posted Transactions, not Settled Transactions, when aligning activity to bank statements.

This report is commonly paired with Prior Day account balances that reflect statement‑aligned closing balances.

Sandbox vs Production Behavior

Posted Transactions behave consistently across environments:

• Same delivery cadence
• Same file structure
• Same header‑only behavior

The primary difference between Sandbox and Production is data realism, not reporting mechanics.

Frequently Asked Questions

Why is my Posted Transactions CSV empty on weekends?

On weekends and bank holidays, transactions may settle but do not post because banks are closed. In these cases, the Posted Transactions report will be delivered with headers only. This behavior is expected.

Why does the posted date differ from the settled date?

Settlement reflects completion within Newline’s processing systems or payment rails. Posting reflects when the transaction appears on the bank statement. These may differ due to rail behavior, processing cutoffs, or weekends and holidays.

Which CSV aligns with bank‑statement activity?

The Posted Transactions CSV is the only report aligned to bank‑statement posting. Settlement‑based reports do not directly correspond to statement dates.

Why is batch_id blank for some ACH entries?

Batch identifiers are populated only when applicable. Received ACH transactions may not be associated with a Newline‑managed batch and may therefore have a blank batch_id.

Why am I not receiving this file?

The Posted Transactions report is currently available on a limited basis and must be enabled for a program. Availability will expand as the report moves toward general availability.

Does posting ever occur on holidays?

Typically, no. While transactions may settle on holidays, posting generally occurs on the next business banking day.