A supplier import can overwrite the wrong part of a departure spreadsheet while colleagues continue making valid booking changes elsewhere. Restoring the entire file to yesterday's state may recover the supplier rows and also remove today's work. A useful recovery decision therefore starts with the scope of the mistake and the changes that need to survive. Google Sheets version history provides evidence, but the agency still has to choose what to recover.
This guide proposes a bounded recovery routine for a travel team using a shared operational spreadsheet. It focuses on an import that changed existing information, rather than a missing file or an inaccessible account. Google's computer instructions for imports and version history were reviewed on 22 October 2026. Use a person with the appropriate file access, coordinate the work with colleagues and keep the original supplier file available for comparison.
Establish what happened before changing more data
Ask the person who performed the import which file they selected, which destination they intended and approximately when they imported it. Identify the spreadsheet by its actual link, then identify the affected sheet or range. Similar names in two open tabs can make a problem appear wider than it is. A precise starting account gives the reviewer something concrete to compare instead of prompting several colleagues to try different fixes at once.
Google's import dialog offers different destinations, with availability depending on the file type. These include creating another spreadsheet, inserting sheets, replacing a spreadsheet or current sheet, appending rows and replacing data from a selected cell. The selected option helps explain why existing content changed. Record what is known; if the operator cannot remember the selection, inspect the result and earlier versions rather than filling the gap with a confident guess.
Agree who will perform the recovery and how other editors should handle the affected area meanwhile. For a small team, a short message through its usual internal process may be enough to pause changes there. Record any urgent booking update arriving during the pause in the normal booking system or another agreed place. The aim is to avoid repairing a moving target while still taking care of travellers whose arrangements need attention.
Identify the valid work that must survive
Suppose a transport supplier sends an updated collection list in the morning. An agent imports it into the shared departure file using the wrong replacement option. Since the previous evening, another colleague has recorded a confirmed pickup change and a new passenger contact number. Those later changes remain useful even if the imported section is wrong. The recovery plan needs to preserve them rather than treat the whole current file as disposable.
Make a concise inventory of the affected departures and the changes known to have occurred after the proposed recovery point. Use booking references and existing confirmation records to establish what matters. You do not need to reconstruct every harmless formatting action before deciding what to do. Concentrate on the operational information that will determine who travels, where they meet the team and what the supplier has agreed to provide.
Also separate the import's intended update from its accidental effects. The new supplier list may contain a legitimate revised vehicle assignment even though it landed in the wrong destination. Keeping yesterday's values everywhere could reintroduce obsolete information. Preserve the source file and identify which supplier changes need to be applied after recovery. This lets the team repair the mistake while still completing the update it actually needed.
Inspect an earlier version without restoring it
On a computer, Google's documented route includes File, Version history and See version history. Browsing earlier versions requires edit permission. Select a relevant timestamp and inspect the file, noting the editor and visible changes. Opening a historical view is an investigation step; do not choose restoration merely because you have found a version whose affected sheet looks familiar.
Compare the area around the import with a version from before it happened. Grouped entries may need expanding, and Sheets can hide unmodified rows in the historical view. If the comparison seems incomplete, use the available option to show those rows. Check the sheet names, column headings and several identifiable booking references rather than relying on the visual shape of a table alone.
Keep a short note of the version that appears useful and the evidence supporting that conclusion. For example, identify that the pre-import transfer sheet contains the expected columns and two known departures, while the current file includes later confirmed client updates. This makes the next decision reviewable by a colleague. It is more useful than saying that a particular timestamp simply looks like the last good version.
Copy the earlier version when comparison is needed
Google documents an option to make a copy of an earlier version from its version-history menu. Give that comparison copy a clear name and choose an appropriate location and sharing arrangement. A historical copy helps separate investigation from the live departure file. It also gives the reviewer a stable reference while the team decides which information should become current again.
Treat the copy as evidence, not as a second operational master. Tell the people involved which spreadsheet will continue to run the departure once the recovery is complete. Otherwise, one colleague may start entering new work into the historical copy while another continues in the original. A clear distinction between the comparison file and the active file prevents that confusion from creating another reconciliation task.
Keep access appropriate to the booking information present. A supplier comparison may not require every contact field or internal note to be circulated to another party. Use the agency's established file-sharing practices, and check the actual recipients before sharing any working copy. The recovery is an internal data task; it does not by itself create a reason to distribute a complete departure register more widely.
Choose between a focused repair and a file restoration
A focused repair may be appropriate when the affected rows or sheet can be identified and later valid work elsewhere should remain current. Use the historical reference and the original supplier file to reconstruct the intended result in the agency's chosen recovery process. Have someone familiar with the sheet's structure handle formulas, references and dependent views rather than treating every cell as interchangeable text.
A whole-file restoration may be appropriate when the damage covers most of the file and the team has accounted for later valid changes. Google's restoration control makes the selected earlier version current. Before using it, agree how those later changes will be reapplied and checked. The decision should reflect the file's real condition, not a rule that restoration is always the easiest or always the wrong response.
If nobody can establish the scope confidently, keep the evidence and involve the person responsible for the spreadsheet before proceeding. An uncertain repair copied across several tabs can make the original mistake harder to understand. Give that person the file link, import source, approximate time, affected departure references and the later updates you know about. A specific handover is much easier to act on than a general request to fix the sheet.
Understand the limits of individual cell history
Google Sheets also provides cell edit history through the cell's context menu. It can help investigate a particular value, but Google's documentation lists omissions, including added or deleted rows and columns, formatting changes and changes produced by formulas. A cell-level view therefore cannot be assumed to explain every structural effect of an import. Use it as one piece of evidence alongside the broader file comparison.
Google also notes that restoring an earlier spreadsheet version clears cell-by-cell history for changes made before the restoration, and recommends making a copy instead when that history needs to be tracked. Consider that consequence before choosing restoration. Do not delete historical versions as part of routine troubleshooting; the present task is to recover a usable operational record, not to tidy away the evidence used to understand the incident.
If a displayed total is wrong, inspect the underlying rows and relevant formulas with the spreadsheet owner. Replacing the visible total alone could conceal an unresolved source problem. Likewise, an apparently correct passenger count does not prove that every passenger row is present once. The useful check depends on the affected data and its role in running the departure.
Verify the recovered departure information
Check the repaired result against the intended supplier update and the valid booking changes identified earlier. For the transfer example, confirm the departure reference, passenger names or identifiers, collection arrangement and any relevant vehicle allocation. Use the records the team normally relies on to confirm those facts. A row count is helpful for spotting an obvious gap, but it does not replace checking the details that changed.
Review dependent materials that use the affected area. These might include the guide's briefing, a transfer list or a printable departure view. Check that they now show the intended result and that the latest confirmed pickup change is still present. Keep the scope tied to the mistake: there is no need to rebuild unrelated itineraries if their inputs were unaffected and the team's normal checks give no reason to doubt them.
Ask a second colleague to review the few consequential changes if the team's process allows it. Give them the evidence and a concise description of the intended outcome. They should be able to confirm that the accidental replacement has been repaired and later accepted updates have survived. Once the reviewer agrees, tell the team which file is current and release the temporary pause on the affected area.
Make the next supplier import easier to check
For a future update, consider importing into a separate sheet or a new spreadsheet first, where the selected format supports that option. Compare the columns and sample departure references before applying changes to the operational area. This is a proposed agency practice, not an automatic guarantee supplied by Sheets. It gives the operator a place to notice an unexpected delimiter, missing column or differently arranged supplier export before replacing live content.
Google Sheets supports naming versions, with a documented limit of fifteen named versions per spreadsheet. A meaningful name before a substantial planned change can make a relevant point easier to locate later. Use names selectively, such as for an important seasonal supplier refresh, rather than expecting an unlimited named checkpoint for every small edit. Follow the team's existing retention and access arrangements for working files.
Finally, record the specific cause and the corrected import step. If the wrong destination option was selected, make that choice explicit in the routine; if the supplier changed its export layout, add the relevant comparison. Preserve what already worked. A short explanation attached to a verified recovery is enough to improve the next update without turning an ordinary supplier-file task into another long, repeated setup exercise.
Related partner guidance
When booking information comes from an editable client intake, keep the review of a requested change distinct from the booking instruction the agency ultimately confirms.
Google Forms edited-intake change-review guide
Sources and further planning
Google Docs Editors Help: find changes, inspect history, copy and restore earlier versions
Google Workspace Learning Center: collaborate in Sheets and open version history
Google Docs Editors Help: import data sets and choose the destination
