Downloaded twice doesn't mean imported twice. Or imported once.

One button, several different events

Start with the question nobody wants to answer during a retry: what actually happened? The export may have been prepared. The file may have reached the laptop. An operator may or may not have submitted it to the intended Tally company. These are different events.

I would not let a download count stand in for an import result. A file can be downloaded repeatedly without being imported once. A single downloaded file can be submitted several times. The browser knows about neither the intended accounting company nor the final voucher outcome.

EntryLedger's Tally XML is explicitly a preview. Actual Tally import, GST-report and voucher-numbering qualification remain unverified. This page describes a handoff record, not a tested recipe for safely retrying every Tally import.

Give the prepared batch an identity

Use the saved export batch as the reference. Record the selected invoices, format and preparation time. A filename such as purchases-final.zip is not enough when several files were created on the same afternoon.

A supplier invoice number alone is also weak. Two suppliers can use the same number. A handoff needs the actual selected invoice records and their supplier identities, not a clerk's memory that “the batch had invoice 84.”

EntryLedger retains selected exports and their original artifacts. That lets you return to the saved batch rather than generate a new file and assume it contains the same snapshot. Historic bytes and a current regeneration can be different if records or mappings changed.

Write the destination company into your external handoff log. Multi-company operators can use the right file in the wrong company. Knowing which laptop downloaded it does not settle that question.

Keep the operator and attempt time as well. The purpose is not to monitor every click. It is to identify who can produce the result when the network or screen leaves the team uncertain.

When the acknowledgement is lost

Suppose the download screen times out. Check saved export history before preparing another batch. If the original is available, retrieve that artifact and identify it clearly. Do not assume the timeout means preparation never occurred.

Now suppose the uncertainty is in Tally, not the browser. Stop and inspect the destination result under the relevant official procedure. A missing “success” message does not prove that nothing was posted. The Tally import help is the reference for your version's behaviour.

Keep any actual error or result output, along with the attempt record. If the destination accepted some records and rejected others, record that distinction. Do not label the whole batch failed merely because the last screen showed an error.

Before retrying, establish which records exist and which need action. This is not a claim about Tally's duplicate-handling rules; those must be checked for the actual import method and version. A second submission should never be justified solely by a lost browser acknowledgement.

The duplicate-invoice check belongs earlier in invoice processing. It is not automatically an idempotency guarantee for every downstream import attempt. Different systems can identify duplicates differently.

What if the invoice changed after preparation?

A saved original export represents the snapshot used when it was prepared. If someone later corrects an invoice or changes a ledger mapping, the original artifact does not magically update. That is the point of retaining it.

Compare the historic batch with the current record before deciding what to use. EntryLedger requires acknowledgement when relevant snapshots changed. A warning should lead to a considered handoff decision, not a reflex click so the download can continue.

If you prepare a new version, identify it as a new version. Retain the relationship to the earlier batch and explain whether the earlier file was never used, partly used or needs a separately authorised correction. Do not erase the first file's history.

Different formats deserve the same discipline. A CSV downloaded as an alternative is not automatically the same import route as the XML. The format comparison helps choose the handoff, but changing formats does not resolve an uncertain prior result.

In particular, masters and vouchers are different artifacts. A successful master preparation or download does not establish that the purchase vouchers were posted. Keep the batch purpose explicit.

Use a handoff log that can say unknown

You can download a blank handoff log. It has no API connection or hidden import automation. Use it to record what your team actually verified.

Unknown is a legitimate status while you investigate. It is better than “failed” when you cannot show failure, and better than “imported” when you only have a ZIP. Name the person responsible for resolving it.

Don't mark invoice records as imported merely because the saved export exists. Export preparation is useful progress, but it does not cross the boundary into the destination books on its own.

The source-to-entry trail should connect the reviewed invoice to the prepared batch. Your destination result then completes the handoff trail separately. A hash or filename helps identify an artifact; it does not prove accounting correctness.

If the original artifact is unavailable or fails integrity checks, treat that as an exception. A regenerated file is not silently interchangeable with the original, especially if your team is investigating what happened to the earlier attempt.

For the next retry, open the handoff log before pressing another button. Find the last event you can prove. Continue from there, rather than repeating the entire process and hoping the second click tells you what the first one did.