Month-end fees | Modulate API

Once a month TSYS collects the fees it did not collect daily, such as statement, regulatory and gateway fees and the month’s discount true-up, as a single debit from the merchant’s bank account. The merchant statement prints it as “Amount Deducted”. GET /api/partner/merchants/{merchant_id}/deposits returns this debit as its own entry with cycle set to MONTH_END.

Identifying the entry

cycle is MONTH_END, and month_end is an object. For every other entry, month_end is null.
amount is signed like any other entry: negative is a debit. The whole amount is reported under fees; card_deposits, chargebacks and other are 0.00.
processing_date is TSYS’s month-end processing day. Use it with date_from / date_to as you would for any entry.
month_end.period_month is the first day of the billing month the fees belong to. The August 2026 debit has period_month 2026-08-01 and a processing date of 2026-08-31.
deposit_id is stable for the merchant and month. It does not change when amount_source changes (see below).

Where the amount comes from

month_end.amount_source is one of two values:

ach_file: TSYS sent a monthly ACH file for the merchant’s bank and month, and the amount comes from that file.
derived: TSYS does not send a monthly ACH file for some banks. The amount is calculated from the TSYS monthly fee report, per fee line, as fee billed − portion already collected by daily ACH, summed across the month. On every month where both sources exist, this calculation matched the monthly ACH file to the cent.

If TSYS starts sending a monthly ACH file for a bank that is derived today, those months switch to ach_file with no change on your side. The deposit_id stays the same.

A month-end entry can be a credit (a positive amount), for example when the daily collections exceeded the month’s fees.

Posting date

effective_on and effective_through are equal for a month-end entry. When month_end.effective_date_is_estimated is true, the date is estimated as the month-end processing date plus two calendar days, moved forward past weekends and Federal Reserve holidays. That rule held on every monthly ACH file we have. As with all deposits, effective dates are processor dates and do not confirm receipt by the bank.

status follows the usual rules: scheduled until the effective date, then debited (or funded for a credit). reconciled is false only when a monthly ACH file amount disagrees with the fee report lines behind it.

Detail

GET /api/partner/merchants/{merchant_id}/deposits/{deposit_id} returns the fee lines behind the debit in month_end_items:

Field	Meaning
`fee_category`, `fee_item`	The fee as it appears on the TSYS fee report, e.g. `MISC Fixed Fees` / `Statement Fee`. `fee_item` can be `null`.
`item_count`	Count the fee was billed on.
`fee_amount`	Fee billed for the month.
`paid_daily_amount`	Portion already collected by daily ACH.
`amount`	Signed contribution to the debit: `-(fee_amount − paid_daily_amount)`.

The item amount values sum to the entry amount. Lines with nothing left to collect are omitted. For month-end entries, lines and related_batches are empty and breakdown has a single FEES row. The batches endpoint does not apply.

Compatibility

MONTH_END is a new cycle value. If you validate cycle against a fixed list, add it, or treat unknown values as OTHER. Month-end debits for banks with a monthly ACH file previously appeared as cycle OTHER fees-only entries with different IDs. Refetch any stored processing-date window that covers a month end, and replace those records rather than appending.