Acknowledgment Patterns: Knowing the Other Side Got It

"Did you get the file?" It is 4:55 p.m. Somebody's month-end depends on the answer. And the honest answer is a shrug: our job said it uploaded, your side hasn't complained, so… probably? Every team that runs a file interface knows that call. It is the interface confessing its missing piece. A file handoff, by itself, tells the producer nothing. Success is inferred from silence, and silence also happens to be what total failure sounds like.

Acknowledgments fix this, but only when you are precise about what each kind actually proves. That is because "we got it" can mean four different things. Most did-you-get-it confusion is two people meaning two different ones. This article lays out the full menu, from doing nothing (deliberately) to cryptographically signed receipts. It gives the exact claim each pattern supports and the cost each one adds. The goal is not the strongest pattern; it is the lightest one that ends the phone calls. I have built the strongest one for a feed that needed the second-lightest, and I would like to save you that afternoon. It is part of our Files as Integration Glue series.

Four Meanings of "Got It"

Think of a mailed letter. It can be delivered to the building, signed for at the desk, opened and read, and finally acted upon. Those are four distinct events, each one a stronger claim than the last. Each one is capable of happening without the next. File handoffs have exactly the same ladder:

1. Delivered — the bytes landed where they were sent. The transfer succeeded; the file sits in the agreed folder.
2. Received — the consumer took possession: its job collected the file from the folder.
3. Readable — the consumer parsed it: structure valid, record count and control totals matching the trailer.
4. Processed — the records were applied to the business system: posted, loaded, made real.

Every acknowledgment pattern proves the ladder up to one rung and not an inch past it. A producer who says "we sent it" is standing on rung one. A consumer who says "we got it" might mean rung two while the producer hears rung four. The first job of an acknowledgment design — and of the interface contract that records it — is to name the rung the interface actually needs. "We sent it" and "we got it" can both be true while nothing was processed.

What an Acknowledgment Proves — and What It Never Does

Before the menu, the fine print, because acknowledgment semantics reward rigor. A protocol-level success — the transfer client reported the upload complete — proves delivery to the server and nothing more. Nobody may ever collect the file. A server log showing the consumer's download proves receipt, not that the parse succeeded an hour later. An ack file written after validation proves the file was readable and its totals matched. It does not prove that the nightly posting job downstream did its work. Even the strongest claim, processed, has a boundary: it proves the consumer applied what was sent, never that what was sent was correct. Garbage, faithfully acknowledged, is still garbage — which is why acknowledgment is a companion to validation before sending, not a substitute for it.

One more boundary matters in disputes. An ordinary ack is a claim by the consumer — a small file saying "we read 8,214 records." It is honest evidence between cooperating teams. It is worthless the day one side suspects the other of rewriting history, because either side could have fabricated it. Turning a receipt into proof — something a third party would accept — requires digital signatures over the received content. That is the top of the menu below.

The Menu, Lightest to Strongest

Each row adds machinery and adds certainty. Find the lowest row that answers the question your phone calls actually ask.

Three of these deserve a closer look, because they carry most of the world's file interfaces.

Transfer-layer evidence (2) is the pattern people forget they already own. When the handoff runs through a shared exchange server, that server's activity log records both halves. It records the producer's upload and — this is the underused part — the consumer's download, with account and timestamp. If the exchange point runs Sysax Multi Server, activity logging to file and database means the producer can answer "did they even fetch it?" The consumer need not build anything at all for that. The evidence reads like this:

Mar 14 02:01  emplfeed   STOR /feeds/empl_elig/in/EMPL_ELIG_YYYYMMDD_01.tmp
Mar 14 02:03  emplfeed   RNTO /feeds/empl_elig/in/EMPL_ELIG_YYYYMMDD_01.csv
Mar 14 02:15  ben-batch  RETR /feeds/empl_elig/in/EMPL_ELIG_YYYYMMDD_01.csv

Upload complete at 02:03, collected by the consumer's account at 02:15 — rung two established, free with the architecture. That happens before either team writes a line of acknowledgment code. What the log cannot say is whether the parse an hour later succeeded. For that, someone must speak. The log is a witness, not a participant.

The ack file (3–4) is the workhorse. After collecting (and, in the stronger form, validating) the data file, the consumer writes a small file whose name mirrors it. This goes into an agreed acknowledgment folder flowing the opposite direction. The rules that make ack files trustworthy are exactly the rules that make data files trustworthy, applied in miniature. Write only after the thing you are claiming has actually happened, never before. Upload under a temporary name and rename, so a half-written ack is never read. And never reuse or overwrite one. An ack that echoes the trailer's numbers back — count read, totals recomputed — is worth far more than a bare "OK". That is because it proves the consumer read the same file the producer sent, not a truncated or stale copy. A worked example:

EMPL_ELIG_YYYYMMDD_01.ack

INTERFACE=EMPL_ELIG
FILE=EMPL_ELIG_YYYYMMDD_01.csv
STATUS=OK
RECORDS_READ=8214
TRAILER_COUNT_MATCH=Y
AMOUNT_TOTAL_MATCH=Y
RECEIVED_AT=Mar 14 02:15
VALIDATED_AT=Mar 14 02:19

The processing results file (5) raises the ack from "we could read it" to "here is what became of it". After the import runs, the consumer returns a results file. It lists records accepted, records rejected, and for each rejection an identifier and a reason code. It is the only pattern on the menu that can answer "did record 84312 post?" That makes it the natural choice when individual records carry real money or real obligations. It also blurs into error handling. A results file with rejections in it is the opening move of a correction cycle between the two teams. The reject-file conventions that make that cycle orderly are covered in the next article. Expect this pattern to cost genuine application work — the import job must track per-record outcomes, not just succeed or fail as a whole.

Acme found out what its silence had been hiding the week it added a results file to a supplier onboarding feed. For a little over a month, the partner's import had been quietly dropping any record whose postal code contained a space. It logged each rejection to a folder nobody on either side watched. The first results file listed fifty-one rejections with the same reason code. The two teams had the cause within an hour: a formatting rule the partner's spec mentioned and Acme's export had never applied. Nothing had failed loudly at any point. The feed had been reporting success on rung one for five weeks while rung four went quietly unfulfilled. That is the exact gap a results file exists to close.

Signed receipts (7) come from the B2B world. The receiver computes a cryptographic digest of what it received, signs it with its private key, and returns that as the receipt. Now the acknowledgment is not merely a claim but evidence — the producer can demonstrate to anyone that this partner received exactly these bytes. This is the MDN mechanism at the heart of AS2 trading (explained in MDNs as proof of delivery). The general design space is covered in proof-of-delivery patterns. It is the right weight when money, regulation, or genuine distrust are in the room. It is overkill for the nightly feed between two teams who share a coffee machine.

The Round Trip, End to End

Whatever pattern you choose from rung three upward, it becomes a loop: file out, acknowledgment back, and a deadline that gives silence a meaning. The diagram shows the full round trip for a nightly feed, with the timing that turns it into an alarm system.

Keep the conventions boring and symmetrical. The ack's name mirrors the data file's name exactly, with only the extension changed, so pairing them needs no lookup table. Acks live in their own folder (ack/) rather than beside inbound data, so neither side's folder watcher triggers on the other side's traffic. And the ack folder gets the same hygiene as any other exchange folder: collected files archived away on a retention schedule. The mechanics are in age-based cleanup jobs. Archiving keeps the folder itself readable as a picture of what is currently in flight. An ack folder nobody archives becomes a museum of every night since launch.

Two design points hide in that picture. First, the producer must actively watch for the ack — an acknowledgment nobody reads is worth exactly as much as no acknowledgment. In practice that is a folder-watching job plus a deadline check. With Sysax FTP Automation, folder monitoring fires a task the moment the ack lands. A scheduled task at the deadline turns the missing ack into a page instead of a morning surprise. It does so with an email notification when its run finds nothing to collect. Second, a negative acknowledgment is still an acknowledgment. An ack with STATUS=REJECTED means the round trip worked and the content failed — a healthy channel reporting a data problem. Silence and rejection are different failures with different responses, and only a deadline separates them.

What Silence Should Mean

Every interface has an acknowledgment policy, whether it was chosen or not. If nothing was chosen, the policy is "silence means whatever each side assumes." That is how a file goes unprocessed for three weeks while both teams believe the other is fine. Choosing means writing two sentences into the contract. What does silence mean before the deadline? (Nothing — processing is in flight.) What does it mean after? (Failure. Not "probably fine." Failure, with a named response.) "Probably fine" is the most expensive phrase in file integration.

The response to post-deadline silence should name a human action — open an incident, call the consumer's on-call — and not an automatic resend. Blind resends into silence are how duplicate batches happen. The file may have been received and processed with only the ack lost. In that case, a resend feeds the consumer the same records twice. The resend, when it comes, follows the contract's sequence-number rule so the consumer can recognize it. The exactly-once thinking article explains why this discipline matters more than it looks. And for interfaces where files only flow occasionally, the consumer side carries its own version of the silence question. It asks "should I have received something by now?" That is answered by freshness checks on expected files rather than by acknowledgment at all.

One distinction saves recurring confusion: a marker file is not an acknowledgment. Markers travel with the data, from the producer, and say "this file is completely written — safe to read." Acknowledgments travel back, from the consumer, and say "we took it and here is what happened." Same technique — a tiny file in a folder — opposite directions, different claims. The producer-side half is covered in marker and control files.

Reconciliation: The Acknowledgment of Last Resort

Per-file acknowledgments share a blind spot: they only speak about files somebody knows about. A file that was never generated draws no ack and no nack — nothing misses it except the schedule. And tiny per-file discrepancies can each pass unnoticed while quietly compounding. The reconciliation report closes both gaps. On a rhythm — daily for high-stakes feeds, weekly or monthly otherwise — one side produces a summary of the period. The summary lists every file received, record counts, and amount totals. The other side compares it against what it believes it sent. Any line that disagrees is investigated; any file on one list but not the other is found within a period, not at year-end.

Reconciliation is how the financial world sleeps at night, and it is cheap to adopt. The consumer usually has the numbers already, and the comparison on the producer side is a small script. For interfaces where each file matters individually, run it alongside per-file acks, not instead of them. The ack catches tonight's failure tonight; the reconciliation catches the failure nobody knew to look for. It is also the pattern that pairs naturally with end-to-end verification of the transfer path itself, covered in verifying transfers end to end.

Choosing the Lightest Pattern That Ends the Calls

Work backward from the phone calls. Each kind of call names the rung of certainty someone is missing, and the menu row that supplies it:

• "Did it arrive?" — Transfer-layer evidence is enough: the exchange server's log answers it in one query. If the caller cannot read that log, a receipt ack (row 3) answers it for them.
• "Did it load okay?" — Validation ack with control-total echo (row 4). This is the sweet spot for most business feeds: one small file ends the largest class of calls.
• "Why do our month-end numbers disagree?" — Reconciliation (row 6), because no per-file ack ever answers a question about the whole period.
• "Prove they received it." — Signed receipts (row 7), because claims stop being enough the moment that sentence is spoken.
• No calls at all, low stakes? — Defined silence (row 1) is a legitimate choice, made honest by writing it down. The consumer monitors, the producer trusts, and everyone knows that is the deal.

Strength costs machinery, and machinery fails too — ack jobs crash, ack folders fill, deadlines fire during maintenance windows. Every rung you climb should be paying for itself in ended phone calls, settled disputes, or satisfied auditors. Climb until the calls stop, then stop climbing. Every rung above that is a hobby.

One Question, Answered Precisely

"Did you get it?" turns out to be four questions wearing one coat: delivered, received, readable, processed. The craft of acknowledgment design is naming which one your interface must answer. It is picking the lightest pattern from the menu that answers it. And it is giving silence a deadline so it becomes information instead of anxiety. Write the choice into the interface contract — pattern, folders, deadline, and the response when the deadline passes. Then the 4:55 p.m. call becomes a log entry both sides can read. The phone can go back to ringing about something else.

Acknowledgments tell you that something failed. The next article in this series, error handling across a file interface, is about what two teams do next. It covers rejects, resends, and the shared evidence that settles whose side broke without a meeting.

Frequently Asked Questions