# Recover an e-invoicing outage without issuing duplicate invoices A timeout tells you that the caller lacks a result. It does not tell you whether the invoice reached the provider, passed validation or became a legal document. Start recovery by establishing the state of the existing attempt. Use the [outage and recovery worksheet](#template) to maintain a single incident record and a document-level backlog. The controls below are recommendations. National rules determine whether you can issue during an outage and what must happen afterward. ## Contain the incident and preserve its evidence Appoint an incident owner who can coordinate billing, integration, tax and the provider. Record the affected entity, service, environment, first failure time and last confirmed successful transaction. Preserve the request payloads, identifiers and raw responses before restarting components. Stop uncontrolled retries for the affected flow while you investigate. Keep unrelated working flows separate. If buyer delivery works but authority reporting fails, the incident record should say so. Do not describe the whole invoice as failed and trigger replacement documents automatically. Give billing a clear operating instruction for new documents and affected orders. Tax approves any issuance restriction or fallback. Customer service needs an agreed explanation and a way to distinguish an existing invoice from a new order awaiting issue. ## Classify the failure before selecting recovery Separate invalid data, authentication failure, rate limiting, local connector failure, provider outage, authority unavailability and an unknown outcome. A rejected document needs a different action from an accepted request whose final processing result is pending. Use the documented query mechanism and original correlation identifiers. MyInvois directs integrations to follow submission processing and warns against repeatedly resubmitting accepted submissions. Its rate-limit responses include Retry-After. [LHDN, integration practices](https://sdk.myinvois.hasil.gov.my/integration-practices/). HTTP defines Retry-After as timing guidance for a subsequent request. Its presence does not independently establish whether your business document was issued or accepted. Interpret it with the endpoint's documented semantics. [IETF, RFC 9110, section 10.2.3](https://www.rfc-editor.org/rfc/rfc9110.html#name-retry-after). If authentication fails, verify the credential, permission and environment before changing invoice data. If content fails validation, send the reason to the data owner. Do not keep the same invalid document in a fast retry loop. ## Ask tax whether a recognized fallback applies Keep technical availability separate from the legal outage category. Record the authority notice or other evidence required by the applicable regime, its time interval and the invoices covered. An operator's inability to connect does not establish that an authority announced an outage. Poland's KSeF guidance distinguishes announced unavailability, outage and total failure. Under its ordinary announced-unavailability mode, invoices follow the applicable electronic structure and are submitted by the next working day after that period ends. Different failure categories have different follow-up rules. [Polish Ministry of Finance, offline mode and KSeF unavailability](https://ksef.podatki.gov.pl/informacje-ogolne-ksef-20/tryb-offline-niedostepnosc-ksef/). Use that as a reason to identify the exact legal mode, not as a general next-day rule. The same guidance contains conditional recipient-delivery and verification requirements. The tax owner must approve the complete branch before billing uses it. For each fallback document, preserve its original number, issue evidence, delivery route and later reporting obligation. A temporary receipt or transaction confirmation must not be silently treated as a substitute invoice unless the applicable rules support that use. ## Work an ambiguous batch without creating new sales Consider a synthetic batch of 100 invoices, each 100 gross in a fictional currency. The intended business population is 100 documents worth 10,000. Assume the approved regime does not require a separate outage issuance mode for these already-issued invoices. The connector submits the batch and times out. After investigation, the documented provider query identifies 70 accepted documents, 20 explicitly rejected for a mapping error and ten with outcomes still unknown. Accepted value is 7,000. Rejected value is 2,000 and unresolved value is 1,000. Retain all 100 business identifiers. Do not send the accepted 70 again. Repair the mapping affecting the rejected 20 and use the provider's approved resubmission process without adding new sales entries. Record the new technical attempt against each original business case. For the unknown ten, obtain reliable outcomes before retrying. Suppose the provider confirms that seven were accepted and three were never received. The already accepted population becomes 77 documents worth 7,700. The safe recovery population is now the 20 rejected plus three confirmed missing, or 23 documents worth 2,300. After approved recovery, obtain confirmed results for those 23. Final accepted value is 7,700 plus 2,300, or 10,000, across exactly 100 business invoices. There may be more than 100 technical attempts. The incident ledger explains why without creating more than 100 sales. If the provider cannot establish the ten outcomes, keep them unresolved and escalate. An estimated success percentage is not enough evidence to retry or close them. ## Recover the backlog in controlled groups Before restarting at volume, verify one representative document in the intended environment. Confirm the corrected mapping, credential or route, then agree a recovery rate within documented limits. Keep new issuance and incident recovery distinguishable in monitoring. Review errors after each recovery group. A new class of failures can indicate that only part of the incident was fixed. Pause the affected subset and avoid converting a small correction into another uncontrolled backlog. Where fallback documents require later submission, reconcile them separately from ordinary retries. Link their eventual authority identifiers to their original legal identity. Confirm the required delivery and reporting actions without asking customers to account for the same sale twice. ## Reconcile financial and customer effects Compare source invoices, accepted records, rejected attempts and open cases in both directions. Confirm counts as well as amounts. A duplicate credit and duplicate invoice may net to zero while both documents remain wrong. Ask billing whether customers received documents or duplicate notices. Ask treasury whether collections or refunds changed during the incident. Tax reviews missed deadlines, corrections and any required notification. These decisions need evidence even when the connector is healthy again. Retain the incident timeline, authority notices, provider responses, repaired mapping and final reconciliation. Separate restored service from cleared backlog and completed statutory follow-up. They can occur at different times. ## Close only after the backlog is explained - ☐ Every affected document has a confirmed outcome or an explicitly owned unresolved case. - ☐ Accepted documents were not recreated as new sales. - ☐ Retry and fallback actions follow documented mechanisms. - ☐ Any national outage category and deadline have tax approval. - ☐ Counts, values, customer delivery and reporting evidence reconcile. - ☐ The underlying failure has a verified fix and monitoring owner. - ☐ Missed-deadline and notification decisions are recorded separately. Use [the status-model guide](https://erplocalization.com/guides/e-invoice-statuses-finance-operations/) to avoid ambiguous dashboard labels and [the correction guide](https://erplocalization.com/guides/correct-cancel-replace-e-invoice/) when the legal document itself needs adjustment. Rehearse this runbook through the existing [acceptance-test process](https://erplocalization.com/guides/erp-localization-acceptance-tests/). Sources checked 17 October 2026. Provider recovery semantics and national fallback conditions require verification in the deployed service. ## Worksheet: E-invoicing incident and recovery record Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment. Show the worksheet Use with [the outage guide](https://erplocalization.com/guides/e-invoicing-outage-recovery/). Preserve original attempts and follow the deployed service's documented query and recovery procedures. ### Open the incident - Incident ID, owner and affected entity: ____ - Service, provider, environment and affected path: ____ - First failure and last confirmed success, with time zones: ____ - Evidence locations and provider contact: ____ - Billing containment instruction: ____ - Tax-approved fallback category, source notice and period if applicable: ____ - Issuance, delivery, later reporting and notification decisions: ____ ### Track each business document - Original legal ID, ERP ID and payload reference: ____ - Attempt and submission identifiers: ____ - Confirmed accepted, rejected or unknown state: ____ - Query evidence and time: ____ - Authorized repair or retry and responsible operator: ____ - Final outcome and accounting impact: ____ - Customer action and remaining statutory obligation: ____ ### Reconcile recovery The synthetic example contains 100 invoices at 100 gross, totaling 10,000. Initial evidence finds 70 accepted, 20 rejected and ten unknown. Investigation confirms seven of the unknown accepted and three not received. Already accepted is 77 documents worth 7,700. Safe recovery covers 23 documents worth 2,300. Final accepted population is 100 documents worth 10,000. - Actual original count and value: ____ - Already accepted count and value: ____ - Confirmed recovery population and final results: ____ - Remaining unknown cases: ____ - ☐ Service restored and backlog cleared are separately evidenced. - ☐ Duplicate attempts did not create duplicate sales. - ☐ Fallback documents retain their original identity. - ☐ Missed-deadline and notification decisions have tax approval. - ☐ Controller approved counts, values and customer effects. Closure approver and date: ____ ## Related on this site - [Country pages](https://erplocalization.com/countries/): key facts with sources - [E-invoicing matrix](https://erplocalization.com/e-invoicing/): country × ERP support - [All guides](https://erplocalization.com/guides/) Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17. Related: [Glossary](https://erplocalization.com/glossary/) – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more). --- Canonical: https://erplocalization.com/guides/e-invoicing-outage-recovery/ · Last updated: 2026-10-17 · Informational only; not tax, legal or implementation advice. Featured placements are paid or promotional and do not affect the compliance data. Data: CC BY-NC 4.0 (commercial use needs a licence: https://erplocalization.com/data-licence/), attribution "ERP Localization (erplocalization.com)".