Delivery Assurance

A partner can lose its connection just after Files.com saves its uploaded file. From the sender's perspective, the delivery is uncertain: retrying can create a duplicate, while doing nothing can leave a genuine failure unresolved. Reliable file exchange needs a defined way to reconcile that state.

Files.com's transfer records and workflow results show how far a delivery has progressed, while the receiving application's acknowledgment establishes whether the data was accepted. Delivery assurance brings that evidence together with a definition of completion and a way to retry safely. It also covers deliveries that never start, such as a scheduled export that the source system fails to produce.

Evidence of Success

Each handoff answers a different question. A successful upload reports transfer completion under the protocol and service's rules, a matching destination checksum confirms the declared bytes, and an import result reports whether the receiving application accepted them. The evidence needs to match the result you are trying to confirm.

These signals have limits. A checksum alone does not identify the sender, and an arrival email can reach you even if the application later rejects the file. Several records confirming arrival cannot replace the application result when that is what you promised the partner.

For example, invoices can reach Files.com and be delivered to the accounting server, while the accounting import rejects an unknown supplier number. The transfer operator needs the delivery records; the accounting owner needs the rejected invoice and import result. Repeating the transfer without correcting the invoice does not complete the job.

At-Least-Once and Exactly-Once Results

At-least-once delivery means each item reaches the recipient one or more times. To pursue that result, a process retries failed or unconfirmed attempts, including some deliveries the receiver has already accepted. The receiver therefore needs to handle duplicates, while the operators need agreed retry limits and a way to resolve attempts that remain unconfirmed.

The business may need an exactly-once business effect, meaning that an operation takes effect once even if its input arrives repeatedly. That requires coordination in the system performing the operation. Completing an upload or preventing a duplicate filename cannot, by itself, keep an accounting application from recording the same invoice twice.

Idempotency means that repeating an operation has the same intended effect as performing it once. This property belongs to a particular operation: replacing a stored file with the same bytes can be idempotent even though repeatedly importing it creates duplicate invoices. The design needs to address the layer where repetition would cause a problem.

An at-least-once transfer with an idempotent receiver is a practical way to tolerate uncertain deliveries. The sender can retry the same invoice, while accounting recognizes its invoice ID and avoids recording it twice. The two businesses need to agree on that behavior; SFTP, FTPS, or an HTTP success code cannot supply it by themselves.

Duplicate Detection

The producer and receiver need a stable identity for a delivery or business transaction. A batch ID, invoice ID, or EDI control number can serve that purpose when the agreement defines its scope and uniqueness. A delivery-specific filename can aid correlation; a reused name such as latest.csv cannot identify each business submission on its own.

The receiving application needs a durable record of the identities it has processed and their outcomes. Its duplicate check and business update also need to work together when two copies arrive at once. Otherwise, both can pass a separate “check then import” step before either records completion. The application owner determines how to enforce that behavior.

A content hash detects repeated bytes, but identical bytes are not always an accidental duplicate: two intentionally separate submissions can contain the same data. Conversely, a re-encrypted PGP copy can have different encrypted bytes while containing the same invoices. Select the identity from the business meaning, using checksums for integrity where appropriate.

A retry keeps the original delivery identity because it is another attempt to complete the same work. A correction needs an agreed revision or replacement rule so the receiver can accept the change without treating it as either an old duplicate or a new transaction. Where reconciliation requires it, retain both the original and revised outcomes.

Receipts Without AS2

For SFTP, FTPS, HTTPS APIs, S3, or WebDAV, agree on the acknowledgment beyond the transfer response if the sender needs one. Options include a response file in a return folder, a callback from the receiving application, an import-status record, or an email appropriate to a human-operated exchange.

For example, a response file can contain the delivery ID, acceptance or rejection, processing time, and any rejection reason. The partners agree on its name and format because the transfer protocol supplies no universal response-file convention. Its purpose also differs from a readiness marker: the sender publishes a marker before processing, while the receiver publishes a receipt afterward.

Files.com file activity notifications can report an arrival or download. Run records and Event Channels can report processing and transfer outcomes. A business application's own acknowledgment is still needed when its acceptance is the promised result. Give partners an agreed way to correlate or obtain the evidence they need.

Guaranteed Delivery in Managed File Transfer

Managed file transfer combines controlled access, transfer execution, records, recovery, and operational responsibility. A “guaranteed delivery” requirement needs an explicit endpoint and outcome: saved to a server, accepted as an AS2 message, or imported into the business application. It also needs a deadline, retry limits, retention, and an escalation path.

A dependable design keeps input recoverable, records attempts and results, and brings missing or failed work to the responsible team's attention. It still depends on the recipient becoming available and the business records being acceptable. Any contractual guarantee comes from the service agreement, including the outcome and limits it defines.

Files.com retries and recovery differ between Syncs and Automation versions. Expectations can detect a delivery that is missing or fails configured checks. Select those controls for the flow rather than assuming one successful transfer test proves ongoing delivery.

Uncertain and Repeated Deliveries

When an acknowledgment is missing, the delivery identity connects the sender's attempt with the receiver's records. Use those records to find out whether the file arrived, processing started, and the business operation committed. That tells you which stage needs a retry and whether obtaining the missing acknowledgment is enough to resolve the uncertainty without repeating completed work.

Test that recovery before production: interrupt a connection near completion, submit the same delivery twice, submit a correction, and omit a scheduled file. Confirm which record or alert exposes each outcome and which team acts on it. Retain the input and evidence for the recovery period agreed with the partner.