Prepare and submit ETAS reporting data to Newline DataMart, validate processing results, and compare reporting outputs with your source records.

How ETAS Reporting Works

The Embedded Transaction Account Solution (ETAS) uses client-provided business and transaction data to support reporting, reconciliation, payment monitoring, and program oversight.

Your implementation includes two separate integrations:

Integration	Role in Reporting	Your Responsibility
API Integration	Provides payment activity and transaction information through Newline services.	Handle API responses and monitor payment outcomes.
Batch File Integration	Supplies business and transaction records to Newline DataMart.	Generate, validate, and submit required files through SFTP, then review processing results.

Business and Transaction Files are submissions from your platform to DataMart, not reports delivered to you. Processing results, response files, and DataMart reporting outputs are separate from those submissions.

ETAS follows a bring-your-own-ledger model. You remain responsible for maintaining customer balances and transaction history. DataMart reporting does not replace your ledger.

Prerequisites

Before you begin:

Initiate ETAS onboarding and identify your technical and data contacts.
Identify the business and transaction source systems used to generate reporting data.
Review the ETAS File Specs and map your source fields to the required layouts.
Configure SFTP connectivity and access to designated directories.
Verify file-upload and response-file-download capabilities.
Confirm submission schedules, reporting periods, control-file requirements, and available reporting outputs with your implementation team.

See the Batch File Integration Guide for connectivity and onboarding steps.

1. Identify the Required Reporting Data

ETAS requires two primary data submissions.

Business File

The Business File provides information about businesses participating in your ETAS program. It supports:

Customer identification
Transaction-to-business association
Operational reporting
Reconciliation
Regulatory monitoring
Exception management

The downloadable specification describes one row per business entity and daily delivery of inserts and updates.

Required information includes:

Business identifiers
Legal name
DBA name
Tax identification information
Address information
Primary phone number

Use the exact column headers and requirements defined in the file specification.

Transaction File

The Transaction File provides transaction-level activity for reporting, reconciliation, and payment monitoring.

Report only payment types supported by your implementation. ETAS integrations may include:

ACH
Domestic wire transfers
Book transfers
Sent and received Instant Payments through The Clearing House RTP® Network

If RTP is enabled for your ETAS program, include reportable sent and received RTP activity for the submission period. Use the Transactional Detail tab in the ETAS File Specs for the applicable network-reference field and its conditional requirements.

The downloadable specification refers to this file as TRANSACTION DETAIL, describes one row per posted transaction, and specifies daily delivery of inserts and updates.

Do not infer program access from all rail-specific fields contained in the shared file layout. Confirm which payment types are approved for your ETAS implementation.

2. Build Files Using the Approved Layouts

Use the ETAS File Specs as the authoritative source for field names, required values, lengths, formats, and conditional requirements.

File Format and Delivery Requirements

Attribute	Requirement
Format	Pipe-delimited CSV
Encoding	UTF-8
Transmission	Approved SFTP channel
Business File Delivery	Daily delta of inserts and updates
Transaction Detail Delivery	Daily delta of inserts and updates
File Naming	Follow the client, environment, file type, and date conventions defined in the specification

A daily delta contains new and updated records rather than a complete historical export.

Confirm delivery schedules during implementation. Daily submission requirements do not imply a specific cutoff time or reporting-output delivery commitment.

Key Transaction Fields

Field	Type and Constraint	Reporting Meaning
`TRANSACTION_ID`	Required string, maximum 50 characters	Identifies the transaction record
`ACCOUNT_NO`	Required string, maximum 15 characters	Identifies the account tied to the FBO account
`AMOUNT`	Required string, maximum 20 characters	Absolute transaction amount
`DCIP`	Required string, maximum 6 characters	Direction indicator (`DEBIT` or `CREDIT`)
`DATE_POSTED`	Required string, 8 characters	Posting date in `YYYYMMDD` format
`DATE_AVAILABLE`	Required string, 8 characters	Funds-availability date in `YYYYMMDD` format

The Transaction Detail file also requires:

TRANSACTION_CODE
TRANSACTION_DESCRIPTION
Applicable rail-specific reference fields

Use DCIP to determine transaction direction. Do not infer debit or credit status from the sign of AMOUNT.

Keep posting dates and funds-availability dates distinct when interpreting transaction activity. This distinction also applies to RTP: do not substitute payment submission or settlement timing for the posting and availability dates required by the file specification.

Control Files

The ETAS file specification includes Business and Transaction Detail control files.

The Transaction Detail Control File contains the record count for the associated Transaction Detail submission.

Confirm:

Applicable control-file layouts
Record-counting requirements
Delivery requirements

with your implementation team before generating control files.

3. Validate Data Before Submission

Validate both file structure and data quality before uploading.

Structure Validation

Use the exact required column headers.
Confirm pipe delimiters and UTF-8 encoding.
Validate required fields, field lengths, and date formats.
Follow approved naming conventions.
Validate conditional requirements.

Completeness and Integrity Validation

Include all records reportable for the submission period.
Verify all business and transaction identifiers are populated.
Remove duplicate records within the submission.
Validate account references and business associations.
Confirm valid transaction amounts and debit/credit indicators.
Compare record counts and transaction totals with source-system extracts.
If RTP is enabled, validate reportable sent and received RTP records and their applicable network-reference fields against the file specification.

Key identifiers include:

Business File identifier: BUSINESSID
Transaction Detail identifier: TRANSACTION_ID

4. Submit Files and Review Processing Results

Follow this submission workflow:

Generate Business and Transaction Detail files from source systems.
Validate file structure, completeness, and data quality.
Generate applicable control files.
Upload files using the approved SFTP channel.
Confirm successful delivery.
Retrieve available response files.
Review processing and validation results.
Correct and resubmit failed records when necessary.

Successful file delivery does not confirm successful processing.

Always review validation and processing results before considering a submission complete.

When correcting data and resubmitting files, verify that duplicate submissions are not introduced.

5. Validate Reporting Outputs

Compare DataMart outputs with both:

Submitted ETAS files
Source-system records

for the same reporting population.

Verify that:

Business counts match source extracts.
Transaction counts match submitted activity.
Debit and credit totals reconcile correctly.
DataMart outputs align with successfully processed submissions.
Ledger balances and payment activity reconcile with expected results.
Processing exceptions and variances are investigated.

Review:

Failed transactions
Returned transactions
Processing variances

as part of your reconciliation process.

Perform reconciliation according to your organization's internal controls and program requirements.

Typical reconciliation activities include:

Daily balancing
Exception review
Variance investigation

Reporting Availability and Timing

The current ETAS documentation establishes required data submissions and reporting-validation responsibilities but does not define:

A customer-facing DataMart report catalog
Output file schemas
Output delivery service levels

Confirm the following during implementation:

Available reporting outputs
Output access methods
Available response files and processing results
Submission and delivery schedules
Correction and escalation procedures

Do not assume that standard Intraday or Prior Day CSV reporting bundles are enabled for ETAS. Their availability, cadence, bundling behavior, and delivery model may differ from ETAS-specific reporting requirements.

Testing and Production Readiness

Complete reporting validation before requesting production approval.

Test Area	Validation Objective
Connectivity	SFTP authentication, directory access, uploads, and downloads function correctly
File Generation	Required files follow approved layouts and naming standards
Data Validation	Required fields, identifiers, dates, amounts, and conditional values validate successfully
Processing	File ingestion and response-file handling behave as expected
Reporting	DataMart outputs align with submitted files and source records
Reconciliation	Business counts, transaction totals, and ledger balances match expected results
Operations	Scheduling, monitoring, exception handling, and escalation procedures are documented

Resolve validation failures and reconciliation discrepancies before production sign-off.

Complete User Acceptance Testing (UAT) and confirm production schedules with your implementation team.

Troubleshooting

Issue	Checks	Next Action
File cannot be delivered	SFTP hostname, credentials, network connectivity, directory permissions	Restore connectivity and verify delivery
Business File fails validation	Required fields, formatting, identifiers, duplicate records	Correct records, regenerate, and resubmit
Transaction File fails validation	Transaction identifiers, amounts, dates, codes, reference values	Review validation results and correct the submission
Business counts differ	Missing records, duplicates, outdated source extracts	Compare source extracts with submitted records
Transaction totals differ	Missing activity, duplicates, timing differences, processing exceptions	Compare record counts and totals against processing results
Reporting outputs do not match submissions	File completeness, validation failures, processing outcomes	Investigate exceptions and escalate unresolved issues

See the ETAS Troubleshooting guide for additional investigation steps.

Support

Contact your assigned implementation or support team if:

Reporting requirements are unclear
Files cannot be processed
Reporting discrepancies remain unresolved

Provide:

Environment
Date and time of the issue
File names
Relevant business identifiers
Relevant transaction identifiers
Error messages
Processing results
Relevant logs
Reproduction steps

Share diagnostic information through approved channels and follow your organization's data-handling policies.

ETAS Reporting Guide