Time	Status	User Agent
Retrieving recent requests…

ACH Export Data

Returns daily ACH deposit records for all merchants in XML format, including batch deposit amounts, NACHA transaction codes, routing details, and fund direction indicators.

ACH Export Data

The ACH export file provides a daily record of all Automated Clearing House transactions for each merchant in your ISO portfolio. It covers merchant service fee ACH entries, direct deposit settlements, and inter-bank fund transfers. The file is used to reconcile ACH activity and track the movement of funds between financial institutions.

When to use

Use this file daily to reconcile ACH settlements against your general ledger. It is the authoritative source for determining which merchants received deposits, the timing of those deposits (DepositDate), and whether any ACH entries are suspended. The DebitCredit NACHA code and SignedAmount fields together determine the direction of each fund movement.

Query Parameters

None. The file is identified by the date path segment (YYYYMMDD) and delivered via SFTP.

Response

200 OK — Returns XML content with the following structure:

XML Hierarchy: Merchant > Transactons > Transacton

Note: The element name in the file is <Transacton> (one i) — this is the native format and must be parsed as-is.

<Merchant> fields:

Field	Type	Description
`MID`	string	Merchant identifier (unique account number)

<Transacton> fields:

Field	Type	Description
`DepositType`	string	Deposit classification: `Batch`, `Fee`, `Adjustment`
`ParentId`	integer	Reference to a parent transaction; null if standalone
`BankNumber`	string	Bank identifier associated with the merchant
`AccountNum`	string	Full merchant account number
`AchPeriod`	string	ACH processing frequency: `Daily`, `Monthly`
`TimeOfDay`	string	Processing time window: `Early`, `Mid`, `Late`, `V` (variable)
`AchTable`	string	ACH table code: `1000` (6PM ET Mon–Fri), `2000` (12AM ET Mon–Fri), `3000` (3AM ET Mon–Fri), `4000` (2PM ET Mon–Fri/Sun)
`AchTableDesc`	string	Human-readable description of the ACH table (e.g. `MERCHANT SERVICE`)
`AchKey`	string	Unique key identifying the ACH entry within the table
`TransactionCode`	string	Internal 4-character code classifying the transaction type
`TransactionNum`	integer	Sequential transaction number within the batch
`ReferenceNumber`	string	16-character external reference number
`Amount`	decimal	Absolute transaction amount in dollars
`SignedAmount`	decimal	Signed amount; negative = debit from merchant account
`RoutingNumber`	string	Masked ABA routing number of the destination bank
`DDANumber`	string	Masked Demand Deposit Account number
`DebitCredit`	string	NACHA transaction code: `22` = checking credit, `27` = checking debit, `32` = savings credit, `37` = savings debit
`OffsetDDA`	string	Masked offset DDA for the balancing entry
`OffsetTR`	string	Masked routing number for the offset account
`OffsetDescription`	string	Description of the offset entry (e.g. `MERCH DEP`)
`Status`	string	Processing status: `MerchantLevelNoRollUp`, `MerchantLevelRollUp`, `AssociationLevelFunding`, `GroupLevelFunding`, `BatchLevel`
`BatchDate`	datetime	Date the ACH batch was submitted
`DepositDate`	datetime	Date funds are scheduled to be deposited
`TransactionDate`	datetime	Date the transaction was created or initiated
`BatchDesc`	string	Optional batch description (empty if not provided)
`SuspendFlag`	string	If populated, the transaction is suspended and will not be submitted to the ACH network
`UpdateDateTime`	datetime	Timestamp of the last update to this record
`AssociationNumber`	string	6-character card association or processing group identifier
`DbaName`	string	Merchant DBA name
`GroupNumber`	string	Group identifier for grouped merchant accounts (empty if not applicable)

<Merchant>
  <MID>9180000000001234</MID>
  <Transactons>
    <Transacton>
      <DepositType>Batch</DepositType>
      <ParentId xsi:nil="true" />
      <BankNumber>9180</BankNumber>
      <AccountNum>9180000000001234</AccountNum>
      <AchPeriod>Daily</AchPeriod>
      <TimeOfDay>V</TimeOfDay>
      <AchTable>2000</AchTable>
      <AchTableDesc>MERCHANT SERVICE</AchTableDesc>
      <AchKey>000090</AchKey>
      <TransactionCode>9017</TransactionCode>
      <TransactionNum>1407</TransactionNum>
      <ReferenceNumber>0000090000001234</ReferenceNumber>
      <Amount>1250.00</Amount>
      <SignedAmount>1250.00</SignedAmount>
      <RoutingNumber>******021</RoutingNumber>
      <DDANumber>**********789</DDANumber>
      <DebitCredit>22</DebitCredit>
      <OffsetDDA>*****01234</OffsetDDA>
      <OffsetTR>****73066</OffsetTR>
      <OffsetDescription>MERCH DEP</OffsetDescription>
      <Status>MerchantLevelNoRollUp</Status>
      <BatchDate>2026-05-27T00:00:00</BatchDate>
      <DepositDate>2026-05-28T00:00:00</DepositDate>
      <TransactionDate>2026-05-27T00:00:00</TransactionDate>
      <BatchDesc />
      <SuspendFlag />
      <UpdateDateTime>2026-05-27T00:00:00</UpdateDateTime>
      <AssociationNumber>999001</AssociationNumber>
      <DbaName>ACME RETAIL STORE</DbaName>
      <GroupNumber />
    </Transacton>
  </Transactons>
</Merchant>

Detailed ACH Reconciliation Guide

This section expands the field documentation using the supplied ACH XML sample. The examples below are based on records actually present in that file. Where the XML sample demonstrates a value but the API definition does not specify a complete business rule, the documentation describes the observed behavior and does not introduce an unsupported enum or interpretation.

1. How to read an ACH record

An ACH record should be interpreted as a fund movement / ledger entry, not simply as a transaction amount.

The most important fields for understanding the financial effect are:

ReferenceNumber — identifies the ACH entry and can be shared by related records.
Amount — absolute amount.
SignedAmount — signed financial amount used for reconciliation.
DebitCredit — NACHA transaction code indicating debit/credit and account type.
OffsetDescription — human-readable description of the entry.
DepositDate — date associated with the merchant deposit.
SuspendFlag — indicates whether an entry is suspended when populated.
Status — describes the funding/roll-up level and should not be treated as a generic success/failure status.

A practical reconciliation view is therefore:

ReferenceNumber
        |
        +-- MERCH DEP  +$X
        |
        +-- PPM FEES   -$Y
        |
        +-- DAILY IC   -$Z
        |
        +-- Net impact = X - Y - Z

The exact combination of entries depends on the merchant and the ACH file.

2. `Amount` vs `SignedAmount`

These two fields have different purposes.

`Amount`

Amount represents the absolute value of the entry.

Example:

<Amount>13.13</Amount>

For both a credit and a debit, Amount can be positive.

`SignedAmount`

SignedAmount represents the financial direction of the entry.

Example of a credit:

<Amount>327.88</Amount>
<SignedAmount>327.88</SignedAmount>

Example of a debit:

<Amount>13.13</Amount>
<SignedAmount>-13.13</SignedAmount>

Therefore:

Amount       = magnitude
SignedAmount = magnitude + direction

Recommended calculation

For reconciliation, calculate the net movement as:

Net ACH Amount = SUM(SignedAmount)

Do not calculate the net movement using Amount without applying the debit/credit direction.

3. Understanding `DebitCredit`

DebitCredit contains a valid NACHA ACH transaction code.

The current API documentation defines these commonly used codes:

Code	Meaning
`22`	Checking credit
`27`	Checking debit
`32`	Savings credit
`37`	Savings debit

The supplied XML sample contains 22 and 27.

Example: checking credit

<Amount>327.88</Amount>
<SignedAmount>327.88</SignedAmount>
<DebitCredit>22</DebitCredit>
<OffsetDescription>MERCH DEP</OffsetDescription>

Interpretation:

$327.88 is credited.

Example: checking debit

<Amount>13.13</Amount>
<SignedAmount>-13.13</SignedAmount>
<DebitCredit>27</DebitCredit>
<OffsetDescription>PPM FEES</OffsetDescription>

Interpretation:

$13.13 is debited.

Why both fields should be retained

DebitCredit tells the consumer how the ACH entry is classified under NACHA, while SignedAmount directly expresses the financial effect.

For reconciliation:

DebitCredit + SignedAmount

provides a stronger interpretation than either field alone.

4. Merchant deposit records

A merchant funding record in the supplied XML has the following observed pattern:

<DepositType>Batch</DepositType>
<AchKey>000090</AchKey>
<TransactionCode>9017</TransactionCode>
<Amount>327.88</Amount>
<SignedAmount>327.88</SignedAmount>
<DebitCredit>22</DebitCredit>
<OffsetDescription>MERCH DEP</OffsetDescription>
<Status>MerchantLevelNoRollUp</Status>

The combination of:

AchKey = 000090
OffsetDescription = MERCH DEP
SignedAmount > 0
DebitCredit = 22

is observed in the sample for merchant deposit entries.

This is a sample-based recognition pattern. Do not treat 000090 or MERCH DEP as an exhaustive list of all possible merchant funding descriptions unless the underlying processor specification confirms that behavior.

5. Fee and adjustment records

The supplied XML also contains entries that reduce the merchant's funding amount.

PPM fees

Example:

<Amount>13.13</Amount>
<SignedAmount>-13.13</SignedAmount>
<DebitCredit>27</DebitCredit>
<OffsetDescription>PPM FEES</OffsetDescription>

The financial effect is:

- $13.13

Daily interchange

Example:

<Amount>1.45</Amount>
<SignedAmount>-1.45</SignedAmount>
<DebitCredit>27</DebitCredit>
<OffsetDescription>DAILY IC</OffsetDescription>

The financial effect is:

- $1.45

Important

A negative ACH record is not necessarily an ACH failure or return.

For example:

PPM FEES   -$13.13
DAILY IC    -$1.45

are deductions/adjustments in the sample, not failed ACH transactions.

ACH failures and collection activity are documented separately by:

GET /download/YYYYMMDD/ACHRejectsCollects

6. Reconciling a merchant's net deposit

A merchant can have multiple records in the same export.

For example, the supplied XML contains a merchant with:

MERCH DEP   +$173.01
PPM FEES      -$5.49
DAILY IC      -$1.45

The net movement is:

173.01 - 5.49 - 1.45
= 166.07

So:

Gross merchant deposit = $173.01
Deductions             = $6.94
Net ACH movement       = $166.07

This is the correct way to reconcile the records: sum SignedAmount, rather than treating every <Transacton> as a separate gross deposit.

7. Using `ReferenceNumber`

ReferenceNumber is a 16-character external reference number.

The supplied XML demonstrates that multiple records can share the same reference number.

Example:

ReferenceNumber: 0000090001280002

MERCH DEP   +$327.88
PPM FEES      -$13.13

These records should be considered together during reconciliation.

Another example from the XML:

ReferenceNumber: 0000090001610012

DAILY IC      -$1.45
PPM FEES      -$5.49
MERCH DEP   +$173.01

Net:

173.01 - 1.45 - 5.49 = 166.07

Recommended grouping

A reconciliation process can group records by:

MID + ReferenceNumber

This is safer than grouping by ReferenceNumber alone because the export contains multiple merchants.

8. `ParentId` and related records

ParentId is defined as a reference to a parent transaction and can be null for a standalone record.

The supplied XML sample has:

<ParentId xsi:nil="true" />

for the displayed records.

Therefore, the sample does not demonstrate a non-null parent-child relationship.

The API definition nevertheless indicates that ParentId can contain a parent transaction reference. When it is populated, consumers should preserve and use it to link the child record to its parent rather than assuming every ACH entry is independent.

Do not invent a parent relationship when ParentId is null.

9. `DepositType`

The API defines:

Batch
Fee
Adjustment

The supplied XML sample shows:

<DepositType>Batch</DepositType>

for merchant deposit entries and also contains records where:

<DepositType xsi:nil="true" />

Important distinction

The value of DepositType should not be inferred solely from the sign of SignedAmount.

For example:

SignedAmount < 0

does not automatically mean:

DepositType = Fee

The XML sample contains null DepositType values on adjustment-style records. Therefore, consumers should preserve the actual field value and use OffsetDescription, AchKey, and the financial fields for reconciliation.

10. ACH processing schedule

`AchPeriod`

The API defines:

Daily
Monthly

The supplied XML sample uses:

<AchPeriod>Daily</AchPeriod>

This indicates that the sample records belong to daily ACH processing.

`TimeOfDay`

The API defines:

Early
Mid
Late
V

The supplied XML sample uses:

<TimeOfDay>Early</TimeOfDay>

`AchTable`

The API documentation defines these ACH table values:

Code	Schedule
`1000`	6:00 PM ET, Monday–Friday
`2000`	12:00 AM ET, Monday–Friday
`3000`	3:00 AM ET, Monday–Friday
`4000`	2:00 PM ET, Monday–Friday and Sunday

The supplied September XML uses:

<AchTable>6000</AchTable>

This value is present in the real sample but is not included in the four allowed values documented by the current API definition.

Therefore, a consumer should not reject the entire file solely because it encounters 6000. Treat AchTable as a provider-defined string and preserve unknown values for forward compatibility.

The sample also does not contain AchTableDesc, although the API model defines the field.

11. `Status` is not a success/failure status

The API defines these values:

MerchantLevelNoRollUp
MerchantLevelRollUp
AssociationLevelFunding
GroupLevelFunding
BatchLevel

The API's underlying descriptions are:

Value	Meaning
`MerchantLevelNoRollUp`	Merchant level, no roll-up
`MerchantLevelRollUp`	Merchant level; transaction destination is R and card types are rolled up for the merchant
`AssociationLevelFunding`	Association-level funding
`GroupLevelFunding`	Group-level funding
`BatchLevel`	Batch-level funding; ACH items are netted from the deposit

The supplied XML contains:

<Status>MerchantLevelNoRollUp</Status>

Do not interpret `Status` as:

SUCCESS
FAILED
PENDING
RETURNED

Those are not the semantics represented by this field.

For example, a record with:

Status = MerchantLevelNoRollUp
SignedAmount = -13.13

can still be a valid fee deduction.

12. `SuspendFlag`

SuspendFlag indicates whether an ACH entry is suspended when the field is populated.

The supplied base documentation specifies:

If populated, the transaction is suspended and will not be submitted to the ACH network.

The sample contains:

<SuspendFlag />

which means no suspension value is populated for that record.

Reconciliation rule

A consumer should check SuspendFlag before treating a future DepositDate as evidence that funds were or will necessarily be submitted.

For example:

DepositDate = 2026-09-02
SuspendFlag = populated

should not be interpreted as a normal submitted ACH movement without additional processing logic.

13. Understanding the date fields

The ACH record contains several dates because they describe different stages of the record.

Field	Meaning
`BatchDate`	Date the ACH batch was submitted
`DepositDate`	Date funds are scheduled to be deposited
`TransactionDate`	Date the transaction was created or initiated
`UpdateDateTime`	Timestamp of the last update to the record

The sample contains:

BatchDate       = 2026-09-02T00:00:00
DepositDate     = 2026-09-02T00:00:00
TransactionDate = 2026-09-02T00:00:00
UpdateDateTime  = 2026-09-02T08:45:35.760

Do not collapse these fields into one date in downstream storage.

UpdateDateTime is especially important because it contains the record update time, including a time-of-day and fractional seconds in the sample.

14. Bank account fields and masking

The export contains:

RoutingNumber
DDANumber
OffsetDDA
OffsetTR

The supplied XML masks these values, for example:

<RoutingNumber>******024</RoutingNumber>
<DDANumber>********433</DDANumber>
<OffsetDDA>*****07650</OffsetDDA>
<OffsetTR>****06768</OffsetTR>

Consumers should preserve these values exactly as provided.

Important

Do not assume that:

RoutingNumber = OffsetTR

or that:

DDANumber = OffsetDDA

They represent different fields in the export.

The sample demonstrates that merchant account details and offset account details are separately represented.

15. `OffsetDescription` as a human-readable classification

OffsetDescription is particularly useful for reconciliation and reporting because it provides a readable description of the ledger entry.

Observed values in the supplied XML include:

Value	Sample interpretation
`MERCH DEP`	Merchant deposit
`PPM FEES`	PPM fee deduction
`DAILY IC`	Daily interchange deduction

For UI/reporting purposes, this field can be displayed alongside the signed amount:

MERCH DEP   +$173.01
PPM FEES      -$5.49
DAILY IC      -$1.45

However, do not use the text description as the only source of financial direction. Use SignedAmount and DebitCredit.

Complete Reconciliation Examples

Example 1: Simple merchant deposit

XML:

<Transacton>
  <DepositType>Batch</DepositType>
  <BankNumber>5581</BankNumber>
  <AccountNum>558137900087205</AccountNum>
  <AchPeriod>Daily</AchPeriod>
  <TimeOfDay>Early</TimeOfDay>
  <AchTable>6000</AchTable>
  <AchKey>000090</AchKey>
  <TransactionCode>9017</TransactionCode>
  <TransactionNum>0</TransactionNum>
  <ReferenceNumber>0000090001570002</ReferenceNumber>
  <Amount>23.02</Amount>
  <SignedAmount>23.02</SignedAmount>
  <RoutingNumber>******024</RoutingNumber>
  <DDANumber>********433</DDANumber>
  <DebitCredit>22</DebitCredit>
  <OffsetDDA>*****07650</OffsetDDA>
  <OffsetTR>****06768</OffsetTR>
  <OffsetDescription>MERCH DEP</OffsetDescription>
  <Status>MerchantLevelNoRollUp</Status>
  <BatchDate>2026-09-02T00:00:00</BatchDate>
  <DepositDate>2026-09-02T00:00:00</DepositDate>
  <TransactionDate>2026-09-02T00:00:00</TransactionDate>
  <UpdateDateTime>2026-09-02T08:45:35.760</UpdateDateTime>
  <AssociationNumber>999002</AssociationNumber>
  <DbaName>FREIGHT 38</DbaName>
  <GroupNumber>000000</GroupNumber>
</Transacton>

Interpretation:

Merchant:          FREIGHT 38
Reference:         0000090001570002
Entry:              MERCH DEP
Amount:             $23.02
Signed impact:     +$23.02
Debit/Credit:       22 (checking credit)
Deposit date:       2026-09-02

This is a positive merchant funding entry.

Example 2: Merchant deposit plus PPM fee

The XML contains these two records for the same merchant and reference:

ReferenceNumber = 0000090001280002

MERCH DEP   +$327.88
PPM FEES      -$13.13

Reconciliation:

327.88 + (-13.13)
= 314.75

Result:

Gross deposit:     $327.88
PPM fees:           $13.13
Net movement:      $314.75

The fee does not replace the merchant deposit record. It is a separate ledger entry.

Example 3: Multiple adjustments against one deposit

The XML contains:

ReferenceNumber = 0000090001610012

DAILY IC      -$1.45
PPM FEES      -$5.49
MERCH DEP   +$173.01

Calculate:

173.01 - 1.45 - 5.49
= 166.07

Therefore:

Gross funding:     $173.01
Daily interchange:   $1.45
PPM fees:            $5.49
Net movement:      $166.07

This is a good example of why ACH reconciliation must operate on all records, not only records where OffsetDescription = MERCH DEP.

Example 4: Multiple deposits for one merchant

The XML contains merchant 558137900087205 with two merchant deposit references:

ReferenceNumber = 0000090001570002
MERCH DEP +$23.02
PPM FEES    -$0.92

ReferenceNumber = 0000090001580019
MERCH DEP +$297.01
PPM FEES     -$11.90

Calculate each reference separately:

23.02 - 0.92 = 22.10
297.01 - 11.90 = 285.11

Merchant total:

22.10 + 285.11 = 307.21

Equivalent direct calculation:

23.02 + 297.01 - 0.92 - 11.90 = 307.21

This demonstrates that a merchant can receive multiple deposit entries in the same daily export.

Recommended Reconciliation Algorithm

A robust implementation can process the file using the following logic:

1. Read each <Merchant>.
2. Read the merchant MID.
3. Read every <Transacton> under that merchant.
4. Preserve all transaction fields exactly as received.
5. Group related records by MID + ReferenceNumber.
6. Use SignedAmount to calculate the financial effect.
7. Use DebitCredit as the NACHA debit/credit classification.
8. Use OffsetDescription / AchKey to explain the entry.
9. Check SuspendFlag before considering the entry eligible for ACH submission.
10. Use DepositDate for deposit scheduling/reconciliation.
11. Use UpdateDateTime to identify the latest record update.
12. Do not treat Status as a generic success/failure status.
13. Do not discard records with null DepositType or ParentId.
14. Preserve unknown provider values for forward compatibility.

Pseudocode

for merchant in merchants:

    mid = merchant.MID

    for tx in merchant.Transactons:

        key = (mid, tx.ReferenceNumber)

        grouped[key].append(tx)

for key, records in grouped:

    net_amount = sum(record.SignedAmount for record in records)

    print({
        "merchant": key.mid,
        "referenceNumber": key.reference,
        "netAmount": net_amount
    })

Recommended Data Model

For downstream reconciliation, retain at least:

MID
DepositType
ParentId
BankNumber
AccountNum
AchPeriod
TimeOfDay
AchTable
AchTableDesc
AchKey
TransactionCode
TransactionNum
ReferenceNumber
Amount
SignedAmount
RoutingNumber
DDANumber
DebitCredit
OffsetDDA
OffsetTR
OffsetDescription
Status
BatchDate
DepositDate
TransactionDate
BatchDesc
SuspendFlag
UpdateDateTime
AssociationNumber
DbaName
GroupNumber

Do not discard fields merely because they are empty in the current sample. Fields such as ParentId, BatchDesc, SuspendFlag, and GroupNumber can be null/empty for one record and populated for another.

XML Parsing Considerations

Native element spelling

The XML uses:

<Transactons>
  <Transacton>

The second element is intentionally spelled:

Transacton

not:

Transaction

A parser must use the native spelling exactly.

Nullable XML elements

The sample uses:

<ParentId xsi:nil="true" />
<DepositType xsi:nil="true" />

and also empty elements such as:

<BatchDesc />
<SuspendFlag />
<GroupNumber />

A consumer should handle all of these as nullable/empty values rather than assuming every element contains text.

Unknown values and forward compatibility

The API definition documents a finite set of values for some fields, while the supplied XML may contain values outside the current documentation.

The clearest example is:

<AchTable>6000</AchTable>

The current API definition documents 1000, 2000, 3000, and 4000, but the supplied XML contains 6000.

Therefore:

treat AchTable as a string;
do not hard-fail parsing on an unknown value;
preserve the original value;
avoid converting provider values into a closed application enum unless the application has an UNKNOWN/fallback state.

The same general principle should be applied to provider-defined fields such as AchKey, TransactionCode, and OffsetDescription.

ACH vs ACH Rejects/Collections

The ACH export and ACH Rejects/Collections export serve different purposes.

`/download/YYYYMMDD/ACH`

Use for:

merchant deposits;
ACH ledger movements;
funding reconciliation;
fees and adjustments;
scheduled deposit information.

`/download/YYYYMMDD/ACHRejectsCollects`

Use for:

failed ACH entries;
NACHA return codes;
collection activity;
recovery workflows.

A negative SignedAmount in the ACH export does not by itself mean an ACH return.

For example:

PPM FEES  -$13.13

is a fee deduction, while an ACH return should be identified from the dedicated ACH Rejects/Collections export and its return code.

Field-by-Field Interpretation Summary

Field	Primary use in reconciliation
`MID`	Identify merchant
`DepositType`	Classify deposit entry when populated
`ParentId`	Link child entry to parent when populated
`BankNumber`	Identify associated bank
`AccountNum`	Identify merchant account
`AchPeriod`	ACH processing frequency
`TimeOfDay`	Processing window
`AchTable`	ACH processing table/schedule
`AchTableDesc`	Human-readable ACH table description
`AchKey`	Identify ACH batch constant / entry key
`TransactionCode`	Internal transaction classification
`TransactionNum`	Transaction sequence number
`ReferenceNumber`	Group related ACH entries
`Amount`	Absolute amount
`SignedAmount`	Financial impact
`RoutingNumber`	Masked destination routing number
`DDANumber`	Masked merchant DDA
`DebitCredit`	NACHA debit/credit classification
`OffsetDDA`	Masked offset DDA
`OffsetTR`	Masked offset routing information
`OffsetDescription`	Human-readable entry description
`Status`	Funding/roll-up level
`BatchDate`	Batch submission date
`DepositDate`	Scheduled deposit date
`TransactionDate`	Transaction creation/initiation date
`BatchDesc`	Optional batch description
`SuspendFlag`	Indicates suspension when populated
`UpdateDateTime`	Last record update timestamp
`AssociationNumber`	Processing/association identifier
`DbaName`	Merchant DBA
`GroupNumber`	Group identifier

Practical Rules for Integrators

Rule 1 — Use `SignedAmount` for money calculations

Correct:

net = SUM(SignedAmount)

Incorrect:

net = SUM(Amount)

unless debit/credit direction is applied separately.

Rule 2 — Use `DebitCredit` as the NACHA classification

For example:

22 = checking credit
27 = checking debit

Do not derive the NACHA code from the sign of SignedAmount.

Rule 3 — Group related records

Use:

MID + ReferenceNumber

when reconstructing the net ACH movement represented by related records.

Rule 4 — Do not treat every negative amount as a reject

Negative entries can represent:

PPM FEES
DAILY IC

as demonstrated by the supplied XML.

Rule 5 — Do not use `Status` as payment status

Status describes the funding/roll-up level.

Rule 6 — Check `SuspendFlag`

A populated SuspendFlag changes how the record should be treated for ACH submission/reconciliation.

Rule 7 — Preserve nullable fields

DepositType, ParentId, BatchDesc, SuspendFlag, and GroupNumber may be empty/null.

Rule 8 — Preserve unknown provider values

Do not assume that the current documentation exhaustively enumerates every value that can occur in production files.

End-to-End Example

Suppose the daily file contains:

MID = 558190100048447

ReferenceNumber = 0000090001610012

MERCH DEP   Amount=173.01  SignedAmount=+173.01  DebitCredit=22
DAILY IC    Amount=1.45    SignedAmount=-1.45    DebitCredit=27
PPM FEES    Amount=5.49    SignedAmount=-5.49    DebitCredit=27

An integrator should report:

Merchant: 558190100048447
Reference: 0000090001610012

Gross deposit:       $173.01
Daily interchange:     -$1.45
PPM fees:              -$5.49
--------------------------------
Net ACH movement:    $166.07

The correct interpretation is:

MERCH DEP → funds credited
DAILY IC  → funds debited
PPM FEES  → funds debited
Net       → +$166.07

This is a funding reconciliation result, not an ACH rejection result.

Important Source/Model Consistency Notes

The current OpenAPI model and the supplied XML sample are not perfectly identical in every observed detail.

Examples:

The OpenAPI model describes transactionCode as an integer, while the business description calls it a 4-position character code. Consumers should preserve leading zeroes if they can occur in the source representation.
The OpenAPI model documents AchTable values 1000–4000, while the supplied XML contains 6000.
The OpenAPI example uses JSON property name tarnsactions, while the native XML uses <Transactons> and <Transacton>. The XML spelling should be parsed as received.
Some XML records have null DepositType even though the schema defines an enum for non-null values.
The XML sample includes fields such as BatchDesc, SuspendFlag, and GroupNumber that may be empty.

These differences should be handled defensively by integrations rather than silently discarded.

Error Codes

Code	When it happens
400	Malformed date format in URL path
401	Invalid or missing Basic Auth credentials
403	User does not have permission for this operation
404	No ACH file found for the specified date
500	Internal server error

Common Mistakes

Parsing <Transacton> as <Transaction> — the element name is intentionally missing the second i and must be matched exactly.
Using Amount alone to determine fund direction — always use DebitCredit NACHA code alongside SignedAmount to confirm whether funds are flowing to or from the merchant.
Ignoring SuspendFlag — suspended entries will not be submitted to the ACH network even if DepositDate has passed.
Treating ParentId as always null — when populated, the entry is a child record (e.g. a fee tied to a parent deposit) and should be linked accordingly during reconciliation.

Related Endpoints

GET /download/YYYYMMDD/ACHRejectsCollects — failed ACH transactions and collection records
GET /download/YYYYMMDD/Transactions — batch and card transaction data
GET /download/YYYYMMDD/ReserveFunding — reserve withholding and net deposit amounts

OpenAPI definition

{
  "openapi": "3.0.0",
  "info": {
    "version": "download",
    "title": "Netevia HQ | Export Data Documentation",
    "description": "Netevia HQ | Export Data Documentation"
  },
  "paths": {
    "/download/YYYYMMDD/ACH": {
      "get": {
        "tags": [
          "ExportData"
        ],
        "operationId": "ExportData_ACH",
        "responses": {
          "200": {
            "description": "OK",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/TsysDirectMerchantAchDepositsDto"
                }
              },
              "text/json": {
                "schema": {
                  "$ref": "#/components/schemas/TsysDirectMerchantAchDepositsDto"
                }
              },
              "application/xml": {
                "schema": {
                  "$ref": "#/components/schemas/TsysDirectMerchantAchDepositsDto"
                }
              },
              "text/xml": {
                "schema": {
                  "$ref": "#/components/schemas/TsysDirectMerchantAchDepositsDto"
                }
              },
              "merchants": {
                "examples": {
                  "response": {
                    "value": [
                      {
                        "mid": "9180000000004242",
                        "tarnsactions": [
                          {
                            "bankNumber": "9810",
                            "accountNum": "9180000000010579",
                            "achPeriod": 0,
                            "achTable": "1000",
                            "achTableDesc": "MERCHANT SERVICE",
                            "achKey": "000092",
                            "transactionCode": 9071,
                            "transactionNum": 28,
                            "referenceNumber": "0000090001084568",
                            "amount": 79.8,
                            "signedAmount": -79.8,
                            "routingNumber": "******350",
                            "ddaNumber": "*****649",
                            "debitCredit": "27",
                            "offsetDDA": "*****01866",
                            "offsetTR": "****73066",
                            "offsetDescription": "MERCH CHBK",
                            "status": 0,
                            "batchDate": "2018-12-14T00:00:00",
                            "depositDate": "2018-12-12T00:00:00",
                            "transactionDate": "2018-12-13T00:00:00",
                            "updateDateTime": "2018-12-12T00:00:00",
                            "associationNumber": "999001",
                            "dbaName": "HOLLY LANES"
                          }
                        ]
                      }
                    ]
                  }
                }
              }
            }
          }
        },
        "summary": "ACH Export Data",
        "description": "Returns daily ACH deposit records for all merchants in XML format, including batch deposit amounts, NACHA transaction codes, routing details, and fund direction indicators."
      }
    }
  },
  "security": [
    {
      "Basic": []
    }
  ],
  "servers": [
    {
      "url": "https://hq.staging.netevia.dev"
    }
  ],
  "components": {
    "securitySchemes": {
      "Basic": {
        "type": "http",
        "description": "Basic HTTP Authentication",
        "scheme": "basic"
      }
    },
    "schemas": {
      "TsysDirectMerchantAchDepositsDto": {
        "type": "object",
        "properties": {
          "merchants": {
            "type": "array",
            "items": {
              "$ref": "#/components/schemas/TsysDirectAchDepositsDto"
            }
          }
        }
      },
      "TsysDirectAchDepositsDto": {
        "type": "object",
        "properties": {
          "mid": {
            "description": "Merchant ID",
            "type": "string"
          },
          "tarnsactions": {
            "type": "array",
            "items": {
              "$ref": "#/components/schemas/TsysDirectAchDepositDto"
            }
          }
        }
      },
      "TsysDirectAchDepositDto": {
        "type": "object",
        "properties": {
          "depositType": {
            "enum": [
              "Batch",
              "Fee",
              "Adjustment"
            ],
            "type": "string"
          },
          "parentId": {
            "format": "int32",
            "type": "integer"
          },
          "bankNumber": {
            "description": "The merchant’s bank number.",
            "type": "string"
          },
          "accountNum": {
            "description": "Merchant ID",
            "type": "string"
          },
          "achPeriod": {
            "enum": [
              "Daily",
              "Monthly"
            ],
            "type": "string"
          },
          "timeOfDay": {
            "enum": [
              "Early",
              "Mid",
              "Late",
              "V"
            ],
            "type": "string"
          },
          "achTable": {
            "description": "Allowed values:\r\n\r\n1000 - 6:00PM ET Monday- Friday\r\n\r\n2000 - 12:00AM ET Monday- Friday\r\n\r\n3000 - 3:00AM ET Monday- Friday\r\n\r\n4000 - 2:00PM ET Monday- Friday and Sunday",
            "type": "string"
          },
          "achTableDesc": {
            "type": "string"
          },
          "achKey": {
            "description": "The number to identify a batch constant.",
            "type": "string"
          },
          "transactionCode": {
            "format": "int32",
            "description": "4 positions character",
            "type": "integer"
          },
          "transactionNum": {
            "format": "int32",
            "type": "integer"
          },
          "referenceNumber": {
            "description": "16 positions character",
            "type": "string"
          },
          "amount": {
            "format": "double",
            "type": "number"
          },
          "signedAmount": {
            "format": "double",
            "description": "Amount with based on \"DebitCredit\" indicator",
            "type": "number"
          },
          "routingNumber": {
            "description": "masked",
            "type": "string"
          },
          "ddaNumber": {
            "description": "masked",
            "type": "string"
          },
          "debitCredit": {
            "description": "Indicates if the amount has been debited or credited.\r\n\r\nThe allowed value is a valid NACHA ACH Tran Code.",
            "type": "string"
          },
          "offsetDDA": {
            "description": "masked",
            "type": "string"
          },
          "offsetTR": {
            "description": "masked",
            "type": "string"
          },
          "offsetDescription": {
            "type": "string"
          },
          "status": {
            "description": "The allowed values are:\r\n* N - Merchant level(no roll up)\r\n* M - Merchant level(Tran Dest = R, roll up all card types for the merchant)\r\n* A - Association level funding\r\n* G - Group level funding\r\n* B - Batch level(ACH items netted from the deposit; use the DDA and T/R from the Batch ACH Setup(MCH/ICH)",
            "enum": [
              "MerchantLevelNoRollUp",
              "MerchantLevelRollUp",
              "AssociationLevelFunding",
              "GroupLevelFunding",
              "BatchLevel"
            ],
            "type": "string"
          },
          "batchDate": {
            "format": "date-time",
            "type": "string"
          },
          "depositDate": {
            "format": "date-time",
            "type": "string"
          },
          "transactionDate": {
            "format": "date-time",
            "type": "string"
          },
          "batchDesc": {
            "description": "20 positions character",
            "type": "string"
          },
          "suspendFlag": {
            "type": "string"
          },
          "updateDateTime": {
            "format": "date-time",
            "type": "string"
          },
          "associationNumber": {
            "description": "6 positions character",
            "type": "string"
          },
          "dbaName": {
            "type": "string"
          },
          "groupNumber": {
            "type": "string"
          }
        }
      }
    }
  }
}

ACH Export Data

ACH Export Data

When to use

Query Parameters

Response

Detailed ACH Reconciliation Guide

1. How to read an ACH record

2. Amount vs SignedAmount

Amount

SignedAmount

Recommended calculation

3. Understanding DebitCredit

Example: checking credit

Example: checking debit

Why both fields should be retained

4. Merchant deposit records

5. Fee and adjustment records

PPM fees

Daily interchange

Important

6. Reconciling a merchant's net deposit

7. Using ReferenceNumber

Recommended grouping

8. ParentId and related records

9. DepositType

Important distinction

10. ACH processing schedule

AchPeriod

TimeOfDay

AchTable

11. Status is not a success/failure status

Do not interpret Status as:

12. SuspendFlag

Reconciliation rule

13. Understanding the date fields

14. Bank account fields and masking

Important

15. OffsetDescription as a human-readable classification

Complete Reconciliation Examples

Example 1: Simple merchant deposit

Example 2: Merchant deposit plus PPM fee

Example 3: Multiple adjustments against one deposit

Example 4: Multiple deposits for one merchant

Recommended Reconciliation Algorithm

Pseudocode

Recommended Data Model

XML Parsing Considerations

Native element spelling

Nullable XML elements

Unknown values and forward compatibility

ACH vs ACH Rejects/Collections

/download/YYYYMMDD/ACH

/download/YYYYMMDD/ACHRejectsCollects

Field-by-Field Interpretation Summary

Practical Rules for Integrators

Rule 1 — Use SignedAmount for money calculations

Rule 2 — Use DebitCredit as the NACHA classification

Rule 3 — Group related records

Rule 4 — Do not treat every negative amount as a reject

Rule 5 — Do not use Status as payment status

Rule 6 — Check SuspendFlag

Rule 7 — Preserve nullable fields

Rule 8 — Preserve unknown provider values

End-to-End Example

Important Source/Model Consistency Notes

Error Codes

Common Mistakes

Related Endpoints

OpenAPI definition

200OK

2. `Amount` vs `SignedAmount`

`Amount`

`SignedAmount`

3. Understanding `DebitCredit`

7. Using `ReferenceNumber`

8. `ParentId` and related records

9. `DepositType`

`AchPeriod`

`TimeOfDay`

`AchTable`

11. `Status` is not a success/failure status

Do not interpret `Status` as:

12. `SuspendFlag`

15. `OffsetDescription` as a human-readable classification

`/download/YYYYMMDD/ACH`

`/download/YYYYMMDD/ACHRejectsCollects`

Rule 1 — Use `SignedAmount` for money calculations

Rule 2 — Use `DebitCredit` as the NACHA classification

Rule 5 — Do not use `Status` as payment status

Rule 6 — Check `SuspendFlag`