A spreadsheet is a photo. The instant you export your catalog, the file starts going out of date, because your shop keeps living. Sales come in and drop your stock. You edit a price on Etsy directly. A customer’s order zeroes out the last of a size. By the time you finish editing the file and re-import it, the sheet in your hands and the shop on Etsy no longer perfectly agree.

That gap is where spreadsheet editing usually gets dangerous, and it is the gap most CSV tools ignore. They treat the file as the truth, push every row, and let whatever was live get flattened underneath. For variations - where a row can mean “set this price,” “remove this offering,” or “I just didn’t include this one” - flattening is exactly how sellers lose work they did everywhere else.

Everlyst handles that gap explicitly. Instead of assuming the file is the truth, it reads each row against what is actually live and decides what the row really means before doing anything.

Every row gets a meaning, not just a value

When you re-import a variations sheet, validation compares it to the current live state of your shop and classifies each row. The categories are the whole idea:

Edit - the offering exists live and the row changes it. Straightforward.
Add - the row describes an offering that isn’t live yet. Something to create.
Delete - the row, or its absence, implies an offering should be removed.
Conflict - the row would overwrite a change that was made live since you exported.
Ghost - an offering exists live that isn’t in your file at all.
Preserve - leave this one exactly as it is.

The reason this matters is that the same raw difference between file and shop can mean completely opposite things, and only the seller knows which. A row missing from the sheet might mean “delete that offering” or “I trimmed my file to the rows I cared about.” A value that differs from live might be a deliberate edit or a stale number from before someone changed it on Etsy. Classifying instead of blindly applying is what lets Everlyst stop and ask the right question instead of guessing.

Deletions you have to mean on purpose

Removing an offering is the most destructive thing a re-import can do, so it is never inferred silently.

If your sheet implies that offerings should be removed - because rows were deleted, or because variations that are live no longer appear - Everlyst flags those as deletions and requires explicit confirmation before any of them happen. You see what would be removed and decide, rather than discovering after the fact that trimming your spreadsheet quietly deleted live variations.

This single guard removes one of the scariest failure modes of spreadsheet editing. The natural way people work in a sheet - cut the rows you’re done with, keep the ones you’re editing - is no longer a way to accidentally amputate part of your shop.

When the CSV would overwrite newer live changes

The conflict case is subtler and just as important. Suppose you export, and while your file sits open, you - or a sale, or a direct Etsy edit - change something live. Now your row carries an old value, and applying it would roll back a newer change without anyone deciding that on purpose.

Everlyst catches this. When a row would overwrite a change made live on Etsy since your export, it is marked as a conflict and surfaced for a “CSV wins” decision. You choose, deliberately, whether the spreadsheet’s value should replace the newer live one. The default is never to clobber fresh data silently. The newer reality on Etsy is treated as something worth protecting until you say otherwise.

That is the difference between a tool that respects your shop as a living thing and one that treats your file as gospel regardless of what happened after you saved it.

Don’t get punished for selling

Then there are ghosts - offerings that are live now but aren’t in your file, usually because you added them after you exported. A naive importer reads “not in the sheet” as “should not exist” and wipes them.

Everlyst does the opposite by default: offerings added after your export are preserved, not deleted for failing to appear in an older file. The principle underneath every one of these rules is the same - editing in a spreadsheet should never quietly cost you the work you did everywhere else. Your sheet is one input, not a kill list for anything it doesn’t mention.

Review, then apply

Put together, the flow is calm and predictable:

Re-import your edited variations CSV.
Validation classifies every row against what’s live - edit, add, delete, conflict, ghost, or preserve.
Confirm any deletions explicitly.
Resolve any conflicts, deciding where the CSV should win.
Apply the reviewed changes through the queue.

Nothing destructive happens behind your back, and nothing applies until you’ve seen what it would do. That is what makes a spreadsheet safe to use against a live shop that never stops moving.

This conflict handling builds directly on how rows are matched in the first place - see why we don’t trust Etsy’s product_id alone - and it lives inside the broader spreadsheet round-trip workflow. And as always, every applied job keeps a snapshot you can undo with Backup & Restore. The full picture is on the features page.