Skip to main content

​
SFTP Export format

When Cash App sync to your ERP is on, Monk writes the payments it has matched to a cash application file in your outbound folder. Your ERP’s payment import loads the file, and your next export confirms what was loaded. For how the integration works overall, see File integration (SFTP).

​
Folders and file names

Each batch has one batch_seq for your whole connection, and contains one cash application file per entity with rows in that batch. Monk names each file <timestamp>_<batch_seq>_<entity_code>_cash_application.csv, all in lowercase, and writes it directly into the outbound folder:
  • <timestamp> is when Monk wrote the batch in UTC, as yyyymmdd-hhmmss, <batch_seq> is padded to six digits, and <entity_code> is your entity code in lowercase.
  • batch_seq starts at 1 and increases by one with every batch, with no gaps. A batch only has files for the entities with rows in it, so an entity’s files can skip numbers, but a number with no files at all means a batch you have not received.
  • Monk uploads each cash application file under a temporary name ending in .tmp and renames it once the upload is complete. Your import must ignore .tmp files and pick up only names ending in _cash_application.csv, so it never reads a partly written file.
  • On Monk-hosted SFTP, you can delete each file once you have loaded it, so the folder only holds files still to load. Otherwise, keep track of the last batch_seq you have loaded.
For your SFTP server, Monk confirms delivery by listing the folder after it renames the temporary file; the connector does not return a durable move result. Monk retries confirmation for up to 25 seconds (five attempts at five-second intervals). If your ERP moves the file before that listing, Monk treats delivery as unconfirmed and resends the same file with the same name, bytes, and line_ids. Your ERP must skip lines it has already loaded. A job that always removes files within seconds can prevent the batch from completing and hold later batches. Leave files in the folder for at least one minute, or move them to an archive folder after processing.

​
How to read a cash application file

Each row is one instruction for your ERP. Rows that share a monk_payment_id belong to one payment: one customer’s payment from one bank deposit. For example, a customer pays two invoices by wire: 7,500.00 for INV-2026-0451 and 2,542.00 for INV-2026-0452. Their bank deducts a 42.00 fee, so 10,000.00 arrives, and your team approves writing off the fee in Monk. Monk writes three rows, all with monk_payment_id MK0000004F2K: Both invoices are now closed in your ERP, and the payment totals 10,000.00, matching the deposit. The write-off does not change the payment’s total.

​
Operations

Which columns each operation fills:

​
Columns

Every file has a header row, and its columns always appear in this order:
The tables below group the columns by what they describe. Monk never adds, removes, renames, or reorders a column, or changes what one means, within a format version. Any such change, including a new column at the end, comes with a new format version that your team switches to when your ERP’s import is ready for it, so a loader that reads columns by position keeps working. Identifying the row The payment (repeated on every row of the payment) The application or write-off Every cash application file already satisfies these rules:
  • A payment’s payment_amount equals the sum of its payment_apply and payment_unapplied rows.
  • Write-offs never change a payment’s total.
  • Every customer and invoice ID comes from your latest export, written exactly as you sent it.
  • A reverse always comes before its corrected rows, in the same file.
  • Every file of a batch is in place before Monk writes the next batch.
  • When Monk sends a payment again, for example after your team retries one flagged as not loaded, it repeats the same rows with the same line_id and monk_payment_id in a new batch, so skipping line_ids you have already loaded prevents a double posting.

​
Loading it into your ERP

  • Load cash application files in batch_seq order.
  • Load each payment, meaning every row that shares a monk_payment_id, completely or not at all.
  • Skip any line_id you have already loaded. Do not rely on your ERP to reject a file sent twice.
  • Skip a reverse whose reverses_id you never loaded.
  • Store monk_payment_id in a field on the payment that appears in your next payments.csv, such as the check number or an external reference.
  • Map write_off_kind to your GL accounts in the import, or give Monk the mapping during setup.

​
Confirming what your ERP loaded

Monk confirms what your ERP loaded when your next export shows it. A payment is confirmed when payments.csv contains its monk_payment_id, and each application is confirmed when that row carries the expected invoice and amount. Payments and applications confirm separately, so ERPs that post a payment first and apply it later are supported. Once a payment comes back, your ERP’s version wins, as for any payment applied there: if your team applied it to different invoices or amounts, Monk follows your ERP. A write_off is confirmed with its payment. A reverse is confirmed when the reversed payment appears in payments.csv with voided true. A payment counts as loaded only once it has posted and appears in your export, so payments your ERP holds for approval are confirmed after they post. A payment or application not seen within three exports is flagged for review in Monk, so a cash application file that was never loaded, rows your import rejected, or payments still waiting for approval do not go unnoticed.