TLDR
For a split group MTG proxy order, keep every player, deck, or project module under a distinct name. Maintain a complete master manifest plus a print-only manifest for each group, verify quantities before checkout, and prepare labeled dividers or containers before delivery. When the cards arrive, sort and count one group at a time. Do not assume the printer will package cards separately by deck or recipient.
The goal is not merely to place one large order. It is to preserve enough structure that every card has an intended destination, missing cards can be identified, and a later replacement or reorder can be reconstructed without guessing.
What is a split group MTG proxy order?
“Split group” is a useful workflow term rather than a formal Magic or printing term. It means placing one checkout that contains multiple separately managed card groups. Those groups might be four players’ Commander decks, several testing decks belonging to one player, or modules for a Cube, battle box, or competitive gauntlet.
The groups should remain separate in your records even if they share a checkout. PrintMTG states that an order can contain multiple decklists and that users can rename, switch between, merge, or delete those lists. That makes separately named lists the natural starting point for this workflow. Merge lists only when you intentionally want their cards treated as one pool.
The current Print MTG Cards upload call to action routes decklist projects to PrintMTG. This establishes the current navigation path, but it does not mean cards will arrive physically divided by player or deck. Plan to perform that separation yourself.
Choose the right grouping model
Decide what each group represents before cleaning or importing any lists. Changing the grouping logic halfway through creates ambiguous duplicates and makes final totals harder to audit.
| Grouping model | What each group represents | Main control point |
|---|---|---|
| Full decks | One complete deck, sideboard, or Commander package | Confirm that every expected component is included |
| Missing cards only | Only cards a player does not already own or share | Retain the complete deck record separately |
| Hybrid shells | A stable deck shell plus a shared staple pool | Record which cards belong to the shell and which come from the pool |
| Cube or project modules | Color sections, archetypes, update waves, or other modules | Use stable module names and avoid accidental overlap |
| Testing gauntlet | One main deck and its associated sideboard or matchup package | Keep revisions and sideboards tied to the correct deck |
If you are still choosing between complete decks, partial batches, and shared-card shells, use the whole-deck versus expensive-cards-only planning framework before building the order. The important decision is whether the printed cards will live permanently in one deck or move between projects.
Build two manifests for every player or deck
A reliable group order needs two records. The master manifest describes the complete intended project. The print-only manifest contains only the cards being produced in this order.
The master manifest
The master manifest remains useful even when someone already owns half the deck. It provides the reference against which owned, shared, omitted, and newly printed cards can be reconciled.
- Stable group code and descriptive name, such as ALEX-KARADOR-R3
- Owner or recipient
- Revision number or export date
- Card name and total quantity needed
- Quantity already owned
- Quantity assigned from a shared pool
- Quantity being printed now
- Selected set, collector number, treatment, or art when version consistency matters
- Status such as owned, shared, print, excluded, or unresolved
- Notes for double-faced cards, tokens, emblems, or other special handling
The print-only manifest
Create the print-only list by filtering the master manifest to cards whose “printing now” quantity is greater than zero. This is the list you clean and import. Do not overwrite the master manifest with it; otherwise, there will be no durable record of why certain deck cards were absent from the order.
This distinction is especially valuable for testing decks that change frequently. The same principle supports the revision and archive workflow described in the competitive deck-testing print guide.
Name every group before importing it
Use names that still make sense when the box arrives weeks later. “Deck 1” and “Sam cards” are fragile labels. A group code combining recipient, project, and revision is easier to match across exports, spreadsheets, imported lists, and physical dividers.
- MAYA-MERFOLK-R2
- LEE-MODERN-YAWG-R1-MAIN
- LEE-MODERN-YAWG-R1-SIDE
- GROUP-CUBE-BLUE-UPDATE-03
- SHARED-FETCHLANDS-2026-01
Keep the same code everywhere. If the imported list has one name, the spreadsheet another, and the physical divider a third, sorting becomes a translation exercise. For platform-specific cleanup, the Moxfield decklist printing workflow shows how to move from a source deck to a reviewable print project without rebuilding it by hand.
Clean and proof each imported list separately
PrintMTG’s decklist guidance describes a quantity-first, one-card-per-line format. It also allows optional headings beginning with “//” and advises removing inline notes that could interfere with card matching. A clean list might therefore use “1 Sol Ring” rather than a card name followed by ownership, price, category, or swap notes.
Import one named group, review it, and then move to the next. PrintMTG states that versions can be adjusted after import and recommends checking imports for matching problems. Pay particular attention to unusual punctuation, special names, typos, set identifiers, and cards with less conventional layouts. These are among the cases highlighted in its supplied import guidance.
Create a manual-review queue
Instead of trying to remember every exception during a final scroll, mark cards that require an explicit decision. A manual-review queue should cover:
- Double-faced cards and modal double-faced cards
- Transform and meld components
- Split cards and Adventures
- Battles and other cards whose second face or orientation matters
- Names with unusual punctuation or multiple parts
- Tokens, emblems, copy tokens, and helper cards
- Alternate-art, showcase, borderless, or specific-set selections
- Any import result that does not match the master manifest
PrintMTG says its DFCs and MDFCs are printed with both sides, but you should still verify that the selected front and back correspond to the intended card and version. A platform capability does not replace project-level proofing.
Reconcile quantities before checkout
For every card line, use this relationship: total quantity needed equals quantity owned plus quantity supplied by a shared pool plus quantity printing now, with any intentional exclusion clearly recorded. An unresolved difference means the group is not ready.
Then reconcile the group total. Compare the expected number of printed cards in the manifest with the imported quantity shown for that named list. Perform this check list by list before checking the combined order total.
- Confirm the commander, companion, or other separately displayed card is included intentionally.
- Check main decks and sideboards as separate components rather than assuming the export captured both.
- Decide whether basic lands are included, excluded, or supplied from an existing land box.
- Check repeated cards and quantities instead of reviewing names alone.
- Assign shared staples to a specific pool rather than silently deleting them from several decks.
- Record tokens, emblems, helper cards, and copy tokens separately from the playable deck count.
- Resolve every item in the manual-review queue.
- Add the approved printed total for all groups and compare it with the combined order quantity.
For shared cards, avoid assigning the same physical copy to two players who may need it simultaneously. A spreadsheet can show that both decks use a card, but it cannot make one card appear at two tables. Name the shared pool and record who keeps it after the session or event.
Prepare the physical sorting system before delivery
Make one physical label for each group code before the package arrives. Suitable containers include labeled deck boxes, resealable bags, card storage rows, or temporary stacks separated by oversized divider cards. Colored sleeves can distinguish recipients, but they are most useful after the initial count rather than as a substitute for one.
Do not describe this as supplier-separated packing unless the supplier has explicitly confirmed that service for the specific order. The evidence here supports maintaining multiple lists within an order, not delivery in deck-by-deck packets.
Use a controlled sorting pass
- Set out containers or dividers in the same sequence as the final manifest.
- Choose one identifiable group and pull only cards that belong to it.
- Count quantities against the print-only manifest, checking off each line.
- Move ambiguous cards to an exception tray instead of guessing.
- Repeat for every group.
- Investigate leftovers only after all expected groups have been counted.
- Record missing, extra, damaged, or mismatched cards with the affected group code and card details.
Sorting by card name first can help when several decks contain overlapping staples, but the final check must happen at deck level. A correct combined total can still conceal one deck with an extra copy and another with a missing copy.
Archive the project before distributing the cards
Once everyone has checked their stack, save enough information to reproduce the decision—not just the original decklists. Store the source exports, cleaned import lists, master manifests, print-only manifests, selected versions, exclusions, final group totals, and the order date in one folder.
If friends are reimbursing the organizer, keep that ledger separate from card quantities. Record each player’s allocated cards and any agreed shared costs without modifying the deck manifests. That keeps financial corrections from accidentally changing the card record.
For version-sensitive projects, save set codes and collector numbers where available. A card name alone may not identify the art, frame, treatment, or printing you approved. Give every revised file a new revision number instead of replacing the previous copy.
Frequently asked questions
Can several MTG decks be included in one proxy order?
PrintMTG states that an order can contain multiple decklists and that those lists can be renamed and switched between. Keep each deck or recipient separately named unless the cards are intentionally being combined into one undivided pool.
How do I order only the missing cards without losing the complete deck record?
Keep the full deck in the master manifest and create a filtered print-only manifest. Mark every card as owned, shared, printing now, excluded, or unresolved. Import only the “printing now” lines, but archive both files.
What if several players need the same shared staple?
Decide whether each player receives a dedicated copy or whether the card belongs to a named shared pool. If it is shared, record its custodian and verify that the decks will not need the same physical copy at the same time.
Can these proxy cards be used in sanctioned events?
PrintMTG describes its products as intended for casual play and playtesting, and its policy page states that they are not for sanctioned events. For event-specific questions, check the current Wizards Play Network rules and policy documents or ask the event organizer before attending.
Final preflight checklist
Before checkout, confirm that every group has a stable name, an owner, a master manifest, a print-only manifest, an approved version selection, a resolved special-card queue, and a verified printed total. Before opening the delivery, place matching labeled containers on the table. Before handing out any stack, count it against its own manifest and save the final project archive.
That is the core discipline behind a manageable group order: combine the checkout, not the records. If each card retains a clear destination from export through distribution, a mixed delivery becomes a sorting task rather than a reconstruction project.