A ManaBox export is one of the better files in this hobby, because it carries a Scryfall id on every row. That one column identifies a printing outright, which means the hard part of most collection migrations — working out which of a card's twenty printings you actually own — is already solved before you upload anything.
What is left is everything the file says about your copy rather than about the card: how many, in what finish, in what condition, in which language. That is where a ManaBox import goes wrong, and it goes wrong quietly, because a row with a wrong condition label still matches a real printing and still lands in your collection looking perfectly correct. Ten minutes in a spreadsheet before the upload beats an hour of corrections after it.
Get the export out of ManaBox
ManaBox writes a collection out as a CSV from inside the app. Look for the export control on the collection itself rather than on a single binder or a deck, and if the label has moved since this was written, check ManaBox's own help rather than any guide's screenshot — menus move between releases, the file format does not.
Two things are worth settling before you tap export.
- Export the whole collection in one file. One file imports as one batch with one review queue, and a single batch is far easier to audit than six partial ones that each half-succeeded.
- Keep the original file. Save it somewhere outside both apps, and do not delete the ManaBox collection until you are satisfied with the result. An export is a snapshot you can re-run an import from, and it is the only copy of your data that belongs to neither app.
If the export offers a choice of format or column set, take the widest one. You can ignore a column you do not need; you cannot recover one that was never written.
Know which columns actually matter
Open the file in a spreadsheet before you upload it. Most of what a ManaBox export carries falls into two groups, and only one of them is worth your attention.
The columns that describe the card — rarity, type, mana cost, a price at export time — are attributes of the printing, and any tracker worth using will look them up for itself. If they are wrong or missing, nothing is lost.
The columns that describe your copy are the ones only you have, and the import can only be as good as they are:
- Scryfall id. The strongest identifier in the file. A row that carries one pins exactly one printing with no ambiguity left over.
- Set code and collector number. The backup identifier, used together with the name. Between them they pin the alternate-art and variant slots that share a name with an ordinary printing.
- Quantity. How many copies of that exact combination you own.
- Finish. Whether the copy is non-foil, foil or etched. These are separately priced objects, not a checkbox on one object.
- Condition. The grade you assigned. An importer cannot invent this and will not second-guess it.
- Language. Which printing language the copy is in, which matters for both identification and value.
- Purchase price. What you paid, if you recorded it. Worth keeping — it is the one number that never comes back if you drop the column.
Sort by each of those columns in turn and the blanks and oddities group themselves together, which is a faster review than reading the file top to bottom.
Check the three columns that quietly go wrong
Matching is the part a ManaBox file gets right. These three are the part it can get wrong without telling you.
Condition. Grading vocabularies differ between apps, and an importer can only map the spellings it knows. ManaArchive's importer recognises the five stored grades — Near Mint, Lightly Played, Moderately Played, Heavily Played and Damaged — along with their common abbreviations and spellings, and anything it does not recognise is stored as Near Mint. That default is deliberate, but it means an unfamiliar grade label turns a played copy into a clean one silently, which overstates both the value and what a buyer will find in the envelope. Sort the column, look at the distinct values, and remap anything that is not one of the five before you upload. Grading a card covers what the grades mean if you need to redo them properly.
Finish. The importer reads the finish column as text rather than as a flag: anything mentioning "etched" is etched, a bare true from a boolean column is foil, anything else mentioning "foil" is foil unless it spells out the negative, and everything else — including an empty cell — is non-foil. That handles the usual spellings, but read what your file actually says rather than assuming. A foil miscounted as non-foil is a pricing error on the most expensive copies you own, and foils, etched and variant printings are exactly where the money in a collection tends to sit.
Quantity. A blank quantity cell is treated as one copy, because plenty of exports omit the column entirely. A cell that carries a value but is zero, negative or not a whole number is treated differently: it imports as one copy and the row is held for review rather than written silently, because guessing at ownership is worse than asking.
Language is the forgiving one. Two-letter codes, three-letter codes and full names all normalise to the same canonical name, so a column of en and ja needs no work.
Import it, and read the result honestly
Pick a destination box for the import. Boxes are the valid target — a binder is a page-and-slot object and an import has no way to know which slot a card belongs in — so the copies land in the chosen box as loose contents, ready for you to place properly later.
Every row then resolves in the same order. The Scryfall id is tried first against the local card mirror. Rows without one, or whose id does not resolve, fall back to set code plus collector number plus name. Anything still unmatched gets one direct lookup, and whatever survives all of that is held for review rather than guessed at.
Expect three outcomes, and read them as three different things:
- Processed. The row matched a printing and became a holding, or stacked onto one you already had. Copies stack when the printing, finish, condition and language all match, so re-importing an overlapping file adds quantity rather than creating a duplicate row.
- Needs review. The row was kept, but nothing confirmed which printing it is. This is the feature, not the failure — a row held back is a row the importer refused to guess at.
- Failed. The row could not be read at all, usually because it had no name column.
A name-only file is worth calling out separately: with no Scryfall id and no set code, there is nothing in the row that says which printing you own, so those rows land in review by design. Getting a file with identifiers is the whole job. If your export came from somewhere other than ManaBox, importing from Moxfield, Deckbox or TCGplayer covers what to check in those files.
Work the review queue while the old app is open
Resolve review rows from the import's own history, where each row keeps the note explaining why it stopped — a Scryfall id that did not resolve reads differently from a set code that matched nothing — and search for the right printing from there.
Do it while ManaBox is still open on your phone, because the fastest way to settle a row is usually to look at what the old system said about it. If a row is genuinely ambiguous, identifying the printing covers reading the card itself: the set code and collector number in the bottom-left corner settle almost every case in a few seconds.
Spot-check, then file the cards
Do not read the whole import. Pick four cards you know well — an expensive one, a foil, a card you own in two different printings, and something in a language other than English — and confirm each landed as the right object with the right grade. If those four are right, the mechanism worked.
Then the physical half. Imported copies sit loose in the destination box until you place them, so working through taking inventory and organizing the collection is what turns a correct database into a collection you can actually find a card in.
Doing this in ManaArchive
ManaArchive's importer resolves each row by Scryfall id first and by set code plus collector number second, holds anything it cannot confirm in a review state, and stores what resolves as printing-level holdings with finish, condition, language and quantity intact. Import history stays available afterwards, so a row you left in review is still there next week. See how it works if your collection currently lives in one app and your trades happen in another.
FAQ
Will importing the same file twice duplicate my collection?
No — it stacks. A row whose printing, finish, condition and language all match an existing holding adds its quantity to that holding rather than creating a second row for the same object.
That is worth knowing in both directions. Re-importing a file you have already imported will double your quantities, because the importer has no way to tell an intentional second copy from an accidental second upload. Import a corrected file only for the rows that changed.
What happens to the rows ManaBox could not identify?
They are kept as review rows rather than dropped or guessed at, with a note saying which identifier fell short. Nothing is written to your collection from a review row until you resolve it, so the queue is safe to leave sitting until you have time.
Does the import keep what I paid for each card?
Yes, when the file carries a purchase-price column. It is stored against the copies from that row, which is what makes any later gain-or-loss figure mean something.
If your ManaBox data never recorded a purchase price, the import cannot invent one, and the copies are recorded as having an unknown cost rather than a cost of zero. That distinction matters: a zero would report the whole sale price as profit. Tracking card values covers the other half of that picture.