ETAS Reconciliation Guide

Reconcile your client ledger, payment activity, submitted files, and Newline DataMart outputs to identify missing records, processing exceptions, and balance differences.

Reconciliation model

The Embedded Transaction Account Solution (ETAS) follows a bring-your-own-ledger model: you maintain customer balances and transaction activity in your own ledger, while funds are held in a Fifth Third Bank-owned custodial account for the benefit of your end users.

ETAS reconciliation spans two integrations:

• API integration: Submit payment instructions and retrieve payment activity and status information.
• Batch File integration: Submit Business and Transaction Files to Newline DataMart for reporting, reconciliation, and monitoring.

Submitting a payment request, delivering a file, and successfully processing that file are separate checkpoints. Review each checkpoint when investigating differences.

Prerequisites

1. Complete API authentication and connectivity setup using the API Integration Guide.
2. Configure SFTP access, designated directories, and response-file retrieval using the Batch File Integration Guide.
3. Map your business and transaction records to the ETAS File Specs.
4. Confirm your reporting period, delivery schedule, and control-file requirements with your implementation team.
5. Identify the ledger records, API responses, submitted files, processing results, and DataMart outputs you will compare.

Perform reconciliation according to your internal operational processes and program requirements. The ETAS FAQs identify daily transaction balancing, exception review, and variance investigation as typical activities.

1. Define the reconciliation scope

Select the environment, reporting period, accounts, and payment activity you will reconcile. Include only the payment rails enabled for your ETAS program:

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

Use the same scope when comparing source records, file contents, and reporting outputs. If RTP is enabled, include reportable sent and received RTP activity for the selected period.

The downloadable specification describes Business and Transaction Detail delivery as a daily delta, containing inserts and updates rather than a full historical population. Validate the complete population reportable for that submission period; do not compare a single delta file directly with all historical records.

2. Validate business records

Compare the Business File with your source business records.

Verify that:

• All required business records for the submission are included.
• Business identifiers are populated and unique.
• Required fields meet the specification’s formatting and length constraints.
• Updates reflect current business information.
• Business counts agree with the source extract.

The exact Business File identifier column is BUSINESSID. Use the exact column headers in the downloadable specification when generating files.

If counts differ, check for missing records, duplicates, and outdated source extracts. Correct validation failures before resubmitting.

3. Validate transaction records and totals

Compare the Transaction File with the source transaction population for the same period.

Key reconciliation fields

The ETAS File Specs document the following fields:

The file also requires TRANSACTION_CODE and TRANSACTION_DESCRIPTION. Review the downloadable specification for all required and conditional fields.

Record and amount checks

1. Compare transaction record counts with the source extract.
2. Confirm that transaction identifiers are populated and that duplicate records are not present.
3. Compare each record’s account, amount, direction, and dates.
4. Calculate debit and credit totals separately using DCIP.
5. Compare those totals with source-system totals for the same population.
6. Validate applicable payment-network references against the file specification.

For RTP records, use the Transactional Detail tab in the ETAS File Specs to validate the applicable network transaction identifier and its conditional requirements. Compare reportable sent and received RTP records with the corresponding source activity and ledger entries.

Because AMOUNT contains an absolute value, do not infer debit or credit direction from its sign.

The Transaction Detail specification describes each row as a posted transaction. Keep DATE_POSTED and DATE_AVAILABLE distinct when investigating timing differences.

4. Confirm delivery and processing

After transmitting files through the approved SFTP channel:

1. Confirm successful delivery to the designated directory.
2. Retrieve available response files and processing results.
3. Review validation failures and processing exceptions.
4. Compare submitted records with the resulting DataMart outputs.
5. Correct rejected records and resubmit when necessary.

Successful upload alone does not confirm successful ingestion. Review processing results before treating a submission as complete.

Where control files apply, use them to validate the submitted population. The downloadable specification identifies a Transaction Detail Control File containing the Transaction Detail record count. Confirm the applicable control-file layout and counting rules with your implementation team before generating it.

5. Compare payment activity and ledger balances

Compare your ledger activity with payment-processing information, submitted transaction data, and reporting outputs.

Review:

• Transaction counts
• Debit and credit totals
• Failed transactions
• Returned transactions
• Processing exceptions
• Ledger balance differences

For API-based payment activity, verify that recorded outcomes agree with the latest available transaction information. If a transaction remains pending, monitor its status, verify processing completion, and review reporting outputs before considering it complete.

Your organization remains responsible for maintaining customer balances and transaction records. DataMart submissions support reconciliation; they do not replace your client ledger.

6. Investigate and resolve variances

Use the following checks to narrow down discrepancies:

After correcting a file, validate it again before resubmission. Check for duplicate submissions as part of your remediation process.

Production-readiness checklist

Before production approval:

• Validate successful and failed payment scenarios for each enabled rail.
• If RTP is enabled, verify that reportable sent and received RTP activity, network references, ledger entries, and DataMart records agree with expected test results.
• Verify Business File counts against source systems.
• Verify Transaction File counts and debit and credit totals.
• Confirm that DataMart outputs align with submitted files.
• Validate ledger balances against expected test results.
• Test response-file handling and validation-error remediation.
• Resolve reconciliation discrepancies.
• Document balancing procedures, exception handling, and escalation contacts.
• Complete User Acceptance Testing (UAT).

The ETAS File Specifications Guide requires discrepancies to be investigated and resolved before production sign-off.

Support and escalation

Contact your assigned implementation or support team when file-processing failures, unexpected payment behavior, or reconciliation differences remain unresolved.

Gather:

• Environment
• Date and time of the issue
• File names
• Transaction and business identifiers
• Error messages and validation results
• Relevant logs or screenshots
• Steps to reproduce the issue

Use approved support channels and follow your organization’s data-handling policies when sharing diagnostic information.

See ETAS Troubleshooting for additional investigation steps.

Related documentation

• ETAS Quick Start Onboarding Guide
• API Integration Guide
• Batch File Integration Guide
• ETAS File Specifications Guide
• ETAS File Specs
• ETAS FAQs