Resend an outbound transaction

EDI is asynchronous: you drop a file on an SFTP server, and what happens to it after that happens in someone else’s system. If a partner emails you a few days later to say they never got your invoice, it’s often pretty tough to figure out why, and the standard approach is just to send it again.

What you want in that moment, though, is the document you already sent. Regenerating an 810 gives it fresh control numbers, so if the first one did land, your partner is now holding two invoices that describe the same thing and disagree about their identity, and someone over there has to decide which is real. Sending the exact bytes again avoids all of that.

On any outbound transaction’s page (open it from EDI Transactions) there is a Resend button at the top of the page. Click it, confirm in the popover that appears, and Tediware re-uploads the stored document to the same partner over the same connection.

What resending does

Say you sent an 810 invoice last Tuesday. It went out with interchange control number 000000512, group control number 1043, and transaction set control number 0001, and it sat in the partner’s SFTP directory until it didn’t. When you hit Resend, Tediware goes back to the stored bytes of that exact document, still carrying:

ISA*00*          *00*          *ZZ*ACMETRUCKING   *ZZ*WALDOMART      *260714*0912*U*00501*000000512*0*P*>~
GS*IN*ACMETRUCKING*WALDOMART*20260714*0912*1043*X*005010~
ST*810*0001~

and hands them straight to the upload node that delivered them the first time, over the same connection and into the same target directory, with those control numbers untouched. Your partner receives a byte-for-byte copy of the invoice they say they never got, so if it turns out they did get it, their system recognizes 000000512 as something it has already seen and will usually treat it as the duplicate it is (some systems reject a re-used control number instead).

You get a toast saying Resend started, because the delivery runs in a background job. Within a moment or two, the new delivery result and its log lines show up on the same trace as the original, so the resend is part of the transaction’s history rather than a separate thing you have to go find.

What it doesn’t do

“Resend” is one of those words that could reasonably mean several different things. Here’s what it doesn’t do.

It does not call the outbound submission path that built the document in the first place. No new control numbers are drawn from the sequence, the EDI is not regenerated from your JSON, and the mapping is not re-run. If you changed a mapping since Tuesday, the resend still sends Tuesday’s bytes.

There is also no second EDI transaction created, and therefore no second billing event. A resend of an invoice is the same invoice, and since billing hangs off the transaction record, nothing special had to be written to keep that right. The only record of the resend is the new delivery result and the logs on the original trace.

If the partner has an outbound notification webhook configured, that webhook does fire again after the file successfully re-uploads, the same way it fired the first time. That one is deliberate: the notification describes a delivery, and a delivery happened.

When you can’t resend

The Resend button only appears when the resend is actually possible, and when it isn’t, it’s because:

• Inbound transactions can’t be resent. This is about pushing bytes back out to a partner, and an inbound document was never yours to send.
• Documents older than the retention window can’t be resent either. Tediware keeps delivered content for 45 days and then hard-deletes it, and once the stored bytes are gone there is nothing left to re-upload. This is the limit you are most likely to hit, and I would rather say it plainly than have you discover it on day 46.
• If the delivery node or its target is gone (the connection was deleted, the flow no longer has an upload node), there is no longer a defined place to send the document, so the resend is refused rather than guessed at.
• It didn’t go out through an outbound flow. The acknowledgments Tediware generates for you are the case you’ll actually meet here: they’re built and uploaded by the acknowledgment dispatcher, outside the node graph, and they ride the trace of the inbound document that prompted them, since that’s the document they exist to answer. Their bytes are never stored as a result, and that trace’s delivery node is the inbound one, so replaying it would drop the partner’s original document into your webhook or SFTP folder a second time while the acknowledgment sat exactly where it was. The guard rejects it rather than doing that. This is about how the document was delivered, not what kind of document it is: if you send a 997 yourself as a transaction set on an outbound flow, it has its own trace and stored bytes and resends like anything else.

About the filename

The resend reuses the original filename. That is the honest reading of “send the exact same file”, and if the file never landed there is nothing to collide with anyway.

If the server rejects a write to a name that already exists, though, the resend will fail on the upload with that server’s error in the trace.