How to Track an MTG Cube in a Spreadsheet Without Turning It Into Work

A useful MTG cube inventory spreadsheet should answer four questions quickly: What belongs in the cube? Where is it stored? What is missing or damaged? What changed since the last stable version? If the sheet asks you to document every draft pick, deck, and card movement, it has stopped being an inventory and become a second hobby.

The simplest reliable setup is one canonical inventory tab, one short change log, and an optional support tab for basics, tokens, emblems, checklist cards, and other pieces that are easy to lose. Track exceptions after each draft instead of re-entering the entire cube.

TL;DR

Use one row per card or printing, with a quantity column for identical duplicates.
Make card name, quantity, status, and storage section the only required fields.
Track missing cards, damaged sleeves, and pending replacements as exceptions.
Keep basics, tokens, emblems, and double-faced-card aids in a separate support inventory.
Reset and count the cube after every event, but update the design in batches rather than editing impulsively.
Create printing exports from a copy of the master sheet so sorting or deleting columns cannot damage the canonical inventory.

Build the smallest spreadsheet that can do the job

Start with two tabs: Inventory and Change Log. Add a Support Kit tab only if your cube carries a substantial land station, token box, emblem set, or double-faced-card accessories. Analytics, draft records, archetype maps, and wish lists can live elsewhere; combining every cube project into one workbook makes routine inventory harder.

Field	Recommended use	Why it earns a column
Card name	Required	Identifies the game piece and supports simple searching.
Quantity	Required	Handles intentional duplicates without creating unnecessary rows.
Status	Required	Use a short dropdown such as Active, Missing, Bench, Replace, or Ordered.
Storage section	Required	Points to a practical box section such as W, U, B, R, G, Gold, Colorless, or Land.
Set and collector number	Optional	Distinguishes a particular printing when art, frame, language, or version matters.
Oracle ID	Optional	Tracks the underlying card identity across reprints.
Role or archetype	Optional	Useful for design analysis, but not necessary for physical inventory.
Component note	Optional	Flags double-faced cards, tokens, emblems, or other supporting pieces.
Maintenance note	Exceptions only	Records a split sleeve, unreadable card, missing token, or replacement action.

Card name and quantity are enough for many singleton cubes. Add printing-level information only when the version matters. An Oracle ID identifies a card’s Oracle identity across reprints, while set and collector number identify a particular printing; the MTGJSON identifier documentation explains that distinction.

If the cube deliberately includes duplicates, keep one row when the copies are interchangeable. Use separate rows when the copies have different printings, storage locations, conditions, or replacement needs. That preserves useful detail without turning four identical Lightning Bolts into four maintenance records.

Map the spreadsheet to the storage system

The sheet should describe how the cube is actually reset. If the box is divided by color and card type, use those same section names in the Storage section column. Do not assign every card a precise numbered slot unless the cube is maintained in a fixed collector order; that level of precision collapses as soon as someone returns one card to the wrong position.

Broad sections are usually enough. A 360-card cube might use color, multicolor, colorless, and land dividers. A larger cube could split each color into creatures and noncreatures. The right granularity is the smallest number of sections that lets the group isolate a counting error quickly.

Use a separate labeled container for supporting components. PrintACube’s export guidance treats basics, tokens, emblems, reminder cards, and double-faced-card materials as items that may require separate checking rather than ordinary cube-list entries. Your support tab can therefore track categories instead of individual objects: basic lands by color, recurring tokens by type, emblems, counters, and double-faced-card aids.

Use an exception-based reset after every draft

In tabletop Cube, the cards are lent to drafters and returned afterward, so the reset is part of the format’s operating cycle rather than optional housekeeping. A good reset catches errors while the last deck, sideboard, and play area are still available.

Collect drafted cards separately from basic lands, tokens, and counters.
Ask each player to check the table, deck box, sideboard, and any cards set aside during deck construction.
Sort the cube into the same broad sections used in the spreadsheet.
Count each section and compare it with the expected quantity for that section.
Inspect only visible exceptions: split sleeves, bent corners, marked backs, illegible cards, or missing components.
Change the status of affected rows. Leave normal rows untouched.
Confirm that the total Active quantity equals the intended cube size before putting the box away.

This workflow scales because most cards generate no data entry. If 358 cards return normally and two need attention, you edit two rows. The spreadsheet records the state of the cube, not the labor of moving every card through a draft.

Track sleeves as batches, not as 360 separate objects

Sleeve consistency matters because visible wear can make individual cards distinguishable. The official Magic Tournament Rules require identical sleeves and identical insertion for sleeved cards in sanctioned play, and note that worn sleeves or cards can become marked. A casual cube draft is not automatically governed by tournament policy, but the underlying maintenance lesson is useful: replace conspicuous sleeves before they reveal information.

Do not give every sleeve its own spreadsheet row. Record the sleeve brand, color, size, purchase batch, and number of unused replacements in a small settings area. On card rows, use the maintenance note only when a specific sleeve needs replacement. For a fuller physical setup, see the guide to sleeving an MTG cube.

Double-faced cards need a declared handling method. Wizards’ published guidance identifies opaque sleeves and checklist cards as ways to conceal double-faced cards. Wizards’ double-faced-card guidance is a useful reference when choosing the approach. In the spreadsheet, a simple DFC flag and a component note such as “opaque sleeve” or “checklist card required” are enough.

Separate the stable list from the update queue

Do not replace an active card in the inventory the moment someone suggests a change. Give proposed additions a Bench or Testing status, then move them into Active only when the physical swap occurs. This keeps the spreadsheet aligned with the box even when design decisions are still unsettled.

The Change Log only needs a few fields: date, card out, card in, reason, and physical status. “Approved” means a design decision was made; “Installed” means the old card left the box and the new card entered it. Treat those as different states.

Batching changes is especially valuable for a printed cube. PrintACube says later changes to a custom cube can be handled by reprinting changed cards instead of rebuilding the entire cube. Keep a Replace or Ordered view so several updates can be produced together. For MTG proxy and playtest-card replacements outside a cube-specific order, ProxyFoundry is another printing route.

A modular model can also reduce churn. Wizards has published a Planar Cube example with a stable 200-card portion and a rotating 360-card module, demonstrating how a cube can distinguish its fixed foundation from its changing material. Your version can be much smaller: mark cards as Core, Rotating, or Test Package and update only the relevant module.

Create exports from the master instead of editing the master

A maintenance spreadsheet and a printing list do not need the same columns. Preserve the detailed master, then create a temporary export containing only the fields required for the next task. PrintACube identifies CSV as useful for spreadsheet review but warns that additional columns create more opportunities for accidental edits.

Before exporting, confirm that filters are cleared and the visible list represents the whole intended cube. Compare the quantity total with the target cube size, then spot-check the first cards, last cards, duplicates, and known special cases. Descriptive filenames such as “pauper-cube-360-v12-2026-10-15.csv” are more useful than “final-final-new.csv.” These checks also match PrintACube’s current export guidance.

If the export is headed to a printing workflow, follow the more detailed Cube Cobra export checklist. Exact-printing requests may require set and collector-number information, while a basic list may need only names and quantities.

Use an event-based maintenance cadence

Trigger	Spreadsheet action	Physical action
After every draft	Mark only missing, damaged, or misplaced exceptions.	Sort, count, inspect visible wear, and reset the box.
When a swap is proposed	Add the candidate to Bench or Testing.	Keep the active cube unchanged.
When a swap is installed	Update Active status and add one change-log entry.	Remove the old card and insert the replacement.
Before a replacement order	Filter Replace or Approved items and save a dated snapshot.	Confirm versions, quantities, DFC needs, and sleeves.
Before a major redesign	Duplicate or archive the current inventory.	Keep the stable version intact until the new module is complete.

This cadence separates operational certainty from design judgment. Reset after every event because the physical state can change every time the cube is handled. Make design changes after recurring evidence, not merely because one card dominated one draft. The broader cube update cadence guide explains how to combine draft feedback with replacement and maintenance batches.

Know when the spreadsheet is doing too much

The system is too complicated if your group avoids updating it, if routine resets require touching every row, or if nobody knows which tab is authoritative. Remove fields that do not change a decision. Color identity, mana value, price, image links, and detailed archetype tags may be valuable for design analysis, but they do not automatically belong in a physical inventory.

The system is too thin if you repeatedly lose track of intentional duplicates, cannot distinguish a missing card from a benched card, order the wrong printing, or finish a reset without knowing whether the cube is complete. Add one field that resolves the recurring ambiguity rather than rebuilding the workbook.

A practical starting template

For most cubes, begin with these Inventory columns:

Card Name
Quantity
Status
Storage Section
Set
Collector Number
DFC or Component Note
Role or Module
Maintenance Note

Use dropdowns for Status and Storage Section, protect formula cells, and avoid merged cells. Create saved views for Active, Missing, Replace, and Bench. The only totals you need at first are active cards, missing cards, and pending replacements.

That is enough structure to maintain a 360-card first build or a much larger modular environment. Let recurring problems justify new columns. The best MTG cube inventory spreadsheet is not the one with the most data; it is the one your playgroup can reset correctly while everyone still remembers where the last card was played.