Reconcile manual outage records before normal processing resumes

A manual workaround is not complete when the main system comes back online. The team must account for work recorded during the outage, prevent duplicate actions and decide which exceptions still need attention. Make that handback part of the continuity plan before a disruption occurs.

This guide is for Australian service and order-processing teams using temporary records during a short interruption. NIST identifies manual alternate processing as one possible continuity option, typically for short disruptions. It is US guidance, not an Australian legal requirement. NIST contingency planning overview

Set limits on what can be done manually. Give every temporary transaction a stable identifier. Separate business service restoration from reconciliation completion. Keep unresolved items visible with an owner instead of declaring the whole outage closed.

Name the business owner who may activate the temporary process, the work it permits and the work that must wait. State how long the arrangement can operate before review and what conditions require it to stop.

Do not allow a spreadsheet or paper form to bypass payment authority, safety controls or necessary customer verification. Some activities should remain suspended when the required controls are unavailable. Decide this with the people responsible for the actual operation.

Australian Government guidance on emergency management provides a broader preparedness context. The transaction method below is an original implementation aid for a business interruption, not a substitute for emergency response procedures. Australian emergency management planning

Use one agreed numbering method for temporary records. Record the original request reference where available, the time and time zone, action taken, operator and current status. Keep the minimum information required for the task and protect access to the temporary record.

Avoid several teams creating separate “master” spreadsheets. Where disconnected work is unavoidable, reserve identifiable number ranges or another controlled method that prevents collisions. Test how those records will be combined before relying on the arrangement.

Mark whether the action has only been requested, authorised, performed or entered into the main system. These are different states. A handwritten order is not proof that goods were dispatched, and a dispatch note is not proof that the customer was charged correctly.

Set a clear cutoff between manual entry and normal processing. Tell each affected team which route to use after the cutoff, including overseas teams. Account for requests that were in progress when the outage began and those received during restoration.

Before entering a temporary transaction into the restored system, check whether it already exists. Use the original reference and relevant business attributes, not just similar names. Preserve a cross-reference from the temporary record to the final system identifier.

NIST SP 800-34 Rev 1 addresses recovery and reconstitution within information-system contingency planning. Treat a successful technical restart as an input to the business handback decision, not evidence that every temporary transaction has been reconciled. NIST contingency planning guide

Assume an invented Melbourne team records 24 temporary requests during an outage. At handback, it confirms that 18 have been entered once into the main system, three already existed there, two were cancelled before action and one has insufficient evidence.

The control total is 24: 18 entered, three matched to existing records, two cancelled and one unresolved. The three existing items are not entered again. The unresolved item remains assigned to an owner; the team does not force it into the system simply to clear the queue.

All numbers are illustrative. A balanced count alone does not prove correctness: the team also checks identities, amounts or quantities where relevant, and the actual action taken. Twenty-four records linked to the wrong customers would still be a failed reconciliation.

Fictional record extending the 24-request example above. All entries below are invented; they show how a balanced population can still contain an unresolved business decision.

Population accountability is 24 ÷ 24 = 100%; resolved disposition is 23 ÷ 24 = 95.8%, rounded to one decimal place. These answer different questions. The first figure means every temporary identifier has a status. It does not mean all work is complete.

For the unresolved request, the operator cannot establish whether the requested action already occurred before restoration. The next step is evidence recovery and authorised resolution, not re-entry merely to remove the exception. Record any amount or quantity separately from the count where relevant.

These indicators are internal examples, not universal acceptance thresholds. A single unresolved high-consequence transaction can prevent handback acceptance regardless of the overall percentage.

Use a safe test set containing a duplicate, a cancellation, an incomplete record and a transaction already in progress. Ask the receiving team to reconcile it through the documented route. Do not send real payments, dispatch goods or contact customers as part of an unapproved exercise.

Record whether the team could identify the cases, preserve the evidence and resolve or escalate exceptions. Link this focused test to a recovery tabletop that tests business decisions when broader coordination needs examination.

Only if the authorised plan allows it and the team can prevent conflicting records. Indefinite parallel processing makes ownership and duplication harder to control.

Assign a business owner with authority over the affected process. Technical staff can confirm system availability; the business owner needs evidence that transaction handling is complete or that remaining exceptions are explicitly accepted and controlled.

No automatic deletion is suggested. Follow the organisation's authorised retention, privacy and evidence requirements. Keep the cross-reference long enough to support required checks, while avoiding unnecessary copies.

QSE Advisory is part of the QSE Advisory brand family. Research and drafting were AI assisted. Examples are hypothetical and do not represent client results or firsthand testing. This article provides general information; apply competent review to consequential decisions.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.