How to clean attendee information before printing conference badges

You open the registration export to send it to your badge printer, and suddenly the little problems look expensive. Someone has entered their job title where their company should be. A group booking has the buyer's name against every ticket. Two registrations look identical, but you're not sure whether deleting one would remove a paying delegate.

The first thing you want to do is separate changes you can safely make from decisions somebody has to confirm. Preserve the original registration records, prepare a separate print file, and check each badge against the ticket or registration that gives its holder access. Fix the information without losing that connection.

Conference registration data cleanup means checking that the right person, with the right access, gets a badge they can actually use. Consistent formatting helps, but it doesn't tell you whether a ticket is valid or whether the name belongs to the person attending. Here's how to get the file ready without creating another problem for your team at the registration desk.

Start with the records that determine admission

Before you touch a spreadsheet, decide which system holds the current registration status. That might be your ticketing platform, a conference registration system, or an agreed combination with clear responsibilities. A print supplier's copy should never become the place where your team decides who has paid or whether a cancellation counts.

Take a fresh export and record when you took it, including the time zone. Keep the original unchanged with restricted access. Work in a separate copy, so you can compare an edited value with what the attendee submitted and recover from a mistake. Use your existing retention policy for these copies rather than keeping every export forever.

Then agree what one row represents. An order may contain several tickets. A person may hold a conference pass and a separate workshop booking. A contact record may describe the buyer rather than every delegate. Your badge file needs the record for the person attending, linked to the relevant admission entitlement.

If your current export repeats the purchaser across a company booking, pause and collect the actual delegate details. Renaming copies of the buyer's row doesn't establish which ticket belongs to whom. Our guide to conference group registration explains the booking responsibilities behind that problem.

Make one person accountable for approving the final file. Other people can resolve questions, but the printer needs an unambiguous answer about which version to use.

Keep identifiers separate from names

A name is something you print. A registration identifier is something you use to find the underlying booking. Treating them as interchangeable causes trouble as soon as two delegates share a name or one person changes how they want to appear on their badge.

Keep the original identifiers supplied by your registration system. Know whether each identifies an order, an individual ticket, a person, or a session booking. Those identifiers do different jobs. An order number on its own cannot distinguish several people within the same purchase, and an email address may belong to the administrator who booked them.

Suppose a company buys passes for several colleagues using one finance address. Repeated emails in that export aren't proof of duplicate delegates. Equally, different email addresses don't prove two registrations belong to different people. Someone may have used a personal address for one booking and a work address for another.

Use names and emails to flag records for review, then inspect their ticket identifiers, status, booking history and available confirmation. Keep the decision attached to the records you reviewed. If you're combining files from different systems, confirm how their identifiers relate before joining anything.

Never create the badge's entry code by substituting a name or email for the credential your admission system expects. A badge that looks correct can still contain a code your scanners cannot recognise.

Decide what belongs in the print file

Ask the printer for its import requirements before rearranging your columns. You need to know the required field names, accepted file format, character support and how it links a badge to a registration. Ask how it reports rejected rows and whether importing the same registration again updates a badge or creates another one.

Your working file can hold the information needed to investigate problems. The production print file should contain only what the agreed badge process requires. Usually, that means approved display information, a record identifier and any permitted credential or badge category. The exact fields depend on your event and supplier.

Avoid including a field simply because it appears in the export. A postal address, payment detail, private registration note or accessibility request doesn't become printing information because the printer accepts another column. A badge can also reveal something sensitive through a category name, so review the meaning of labels before you send them.

The UK's Information Commissioner's Office describes data minimisation as keeping personal data adequate, relevant and limited to what the purpose needs. Apply that practical question to every column. Why does this person or system need this information to produce the badge?

For the wider supplier arrangements, including access and deletion, use our guide to sharing attendee data with event suppliers.

Keep personal information out of filenames and email subjects when you send corrections. Use the agreed registration reference inside the restricted process instead. A supplier needs enough information to find the affected badge, but a message forwarded between production staff shouldn't expose private booking notes. If you use a shared folder, confirm who can open it and remove access when their part of the job ends, according to your agreed arrangements.

Fix obvious formatting without rewriting people's names

You can remove an accidental space before a company name. Deciding that someone's name has the wrong capital letters is a different kind of change. Keep that distinction clear when you decide what to correct automatically.

The W3C's guidance on personal names around the world explains why forms and databases should accommodate different name structures, punctuation and scripts. It also advises against forcing names into standard capitalisation. Those details matter when your next step is putting the name on something the attendee will wear.

Don't run a blanket title case conversion across the name column. Preserve accents, apostrophes, hyphens and the order the attendee supplied unless they ask you to change them. A single name, an unfamiliar spelling or several family names should not automatically send a registration into the error list.

If you want a shorter display name, ask for it explicitly. Keep the attendee's confirmed badge name separate from any legal or billing name the event genuinely requires. Staff need to understand which one they should see when helping someone at collection.

A sensible cleanup rule might remove accidental spaces at the beginning or end of a field while preserving the original value. More substantial changes need review. Write down the rules before applying them to the whole file, and test them on copies of difficult records first.

Separate missing information from optional information

A blank cell isn't automatically a mistake. Someone may have no company affiliation, may prefer not to display a job title, or may be attending independently. If those fields are optional, leave them blank rather than inventing something to make the file look complete.

Decide what is required for admission, what is required for badge production and what is merely useful for networking. The same information won't necessarily appear in every group. A ticket identifier can be essential to your process while a company name remains optional.

Your review list should explain what needs resolving and why. "Badge name missing" is useful. "Incomplete attendee" tells a colleague very little and may encourage them to chase information you don't need. If a mandatory field contains "TBC" or the buyer's repeated name, treat that as an unresolved assignment rather than a finished registration.

Give the owner of a company booking a clear request for delegate information and a deadline that matches your production schedule. Tell them which details will appear on the badge. For individual delegates, offer the existing approved correction method rather than asking everyone to email spreadsheets back and forth.

If you can't obtain an optional field before printing, leave it off. If you can't establish who is entitled to collect a badge, keep that record for controlled resolution. Cosmetic completeness should never decide whether you issue a credential.

Review possible duplicates before removing anything

A duplicate check should produce questions, not silently delete registrations. Start by looking for repeated identifiers within the same export. If an individual ticket appears twice, find out whether the export repeated it because it joined ticket information with session selections or other related records.

Next, review registrations with similar names or contact details. An exact name match can belong to two different people. A spelling variation can belong to one person. Neither observation settles whether the event owes one badge or more than one.

Look at the booking purpose and access attached to each record. A delegate might legitimately hold separate credentials for different event days, or a member of staff might also have bought a conference ticket. Decide the badge arrangement from the event's rules and actual bookings. Don't make a spreadsheet formula decide it for you.

When you confirm a duplicate purchase, resolve it through the registration and payment process before excluding anything from production. Deleting a print row doesn't cancel a ticket, issue a refund or stop an old credential working. Record who approved the resolution and how the remaining registration will be identified.

If the case remains ambiguous, send it to someone authorised to decide. Your printer can hold a badge while you investigate. Recovering a deleted delegate record after they arrive is a much worse use of everyone's time.

Work through a mixed company booking

Consider an illustrative booking for a company sending several colleagues. The export includes the same purchaser email on every ticket, a delegate whose company field is blank and a registration marked cancelled. Another colleague has a separately booked workshop. This is exactly where a quick duplicate removal can make the file worse.

Start with the individual ticket identifiers and current statuses. Keep the shared purchaser address because it explains the booking relationship. Confirm that each active conference ticket has an assigned delegate. Leave the cancelled ticket out of the approved production batch under your event's rules, while preserving its registration history in the source system.

For the person with no company listed, ask whether they want the company displayed. Don't copy it from a colleague simply because the tickets came through the same order. They may be attending as a contractor, or may prefer their name alone. That choice doesn't change whether their conference ticket is valid.

Now inspect the workshop booking. Link it to the correct delegate using the supported booking relationship, rather than matching the shared purchaser email. Confirm whether your badge arrangement needs a separate workshop credential or whether staff will look up the entitlement electronically.

Before approving the file, read the result back as an operational decision. Each approved badge belongs to an assigned delegate with a current entitlement. The shared buyer still receives the appropriate booking administration. The cancelled registration remains traceable, and the workshop belongs to the person who booked it. None of those conclusions depends on making every email or company field unique.

Reconcile access before you approve the badge category

A correct name on the wrong badge can be harder to catch than a spelling error. Your team sees a polished badge and assumes the registration behind it has been checked. Review access while you still have the booking information available.

Compare the proposed badge category with the current ticket or registration status. Check cancelled tickets, refunded bookings, approved substitutions and any access changes. Use your event's actual admission rules. A complimentary pass may be valid, and a payment arrangement may need a specific approval rather than an automatic rejection.

Keep access categories separate from marketing descriptions. "Partner" might describe someone's relationship with your company, while "Exhibitor" determines which areas they can enter. If a badge carries both, staff need to know which information grants access and which simply identifies a role.

For conferences with bookable sessions, confirm whether the main badge credential connects to session entitlements. Don't infer workshop access from a company name or from the fact that someone has a conference pass. The registration system and published booking rules should determine it.

Agree how staff will check access if the badge text and live record disagree. Your team needs a named person who can investigate and approve a correction. Letting each desk improvise its own answer creates inconsistent treatment and makes later reconciliation harder.

Handle substitutions as registration changes

A request to print a different person's name can be a simple spelling correction, or it can mean the original delegate is no longer attending. Ask enough to tell the difference. Updating the badge name alone may leave the admission record assigned to somebody else.

Use the transfer or substitution procedure your event already permits. Confirm who can authorise the change, which booking it affects and whether anything else must change with it. That might include a session reservation, an attendee account or the credential used at the door.

Keep the original and replacement details in the appropriate restricted record, with the reason and approval. Your printer needs the approved current information, not an email chain containing every version. If a badge has already been produced, mark it for withdrawal or replacement so staff don't hand out both versions.

Avoid treating a forwarded ticket as permission to change everything attached to the booking. Follow your event's verification process, especially where a third party made the purchase. An employee leaving a company, for example, doesn't tell you by itself who can reassign their place.

Late substitutions need the same decision rules as early ones. You can simplify the route by assigning an authorised person to handle them, but the urgency doesn't remove the need to connect the replacement delegate with the right entitlement.

Protect ticket codes when you open the spreadsheet

Some of the worst errors happen before anyone edits a cell. A spreadsheet program may interpret an identifier as a number or date, then change the value when it opens the file. The column can look tidy while the ticket codes are already damaged.

Microsoft explains how Excel can remove leading zeros and change long numbers in its guidance on preserving leading zeros and large numbers. Use the import process to set identifier columns as text before loading the data. Changing the display format afterwards cannot reliably recover a value that has already changed.

Check every identifier field, including codes you don't intend to print visibly. Keep a few known examples from the source export and compare their complete values after import and after export. Don't rely on the shortened value displayed in a narrow spreadsheet column.

Leave original entry credentials untouched unless your ticketing system's supported process replaces them. A shortened code or a newly generated number may fit the printer's field, but that doesn't make it valid at check-in.

Also use your organisation's approved way of opening files from external sources. Attendee submitted text should remain text rather than becoming an instruction executed by the spreadsheet. Ask your technical or security contact to confirm the import method if your team is unsure how that protection works.

Test the exported file in the printer's actual import

Saving a CSV doesn't prove the receiving software will read it correctly. A company name containing a comma can move text into the wrong column if the export isn't handled properly. A line break inside a response can create another apparent record in an unsuitable import.

The RFC Editor's RFC 4180 description of CSV files documents quoting for fields containing commas, quotation marks and line breaks. For your event, the useful action is to use a supported exporter and test the resulting file with the supplier's importer. Don't repair a CSV by deleting punctuation from people's names.

Confirm the character encoding too. UTF-8 is a way of representing text that can preserve different scripts and accented characters. The export, import and printing software all need to handle the text you send. Ask the supplier to test the actual characters in your file rather than saying its system supports international events.

Review the import report. Rejected rows need an explanation and an owner. Successful rows need checking too, because a system may accept an incorrect column mapping without reporting an error.

Compare the number of imported records with the approved file, then inspect individual values. Count agreement won't catch a company column mapped to the job title field. You need to verify both the totals and what the imported information actually says.

Ask attendees to confirm the information that will appear

Once you've resolved the structural problems, ask delegates to confirm their badge details using a controlled process. Show the actual proposed display information where your system allows it. A generic request to "check your registration" leaves people guessing which name or company field you're about to print.

Your message can be straightforward. "We're preparing conference badges. Please check the name and company you want displayed, and send corrections through your registration account by the deadline below." Explain what happens after the deadline and where someone can get help if they can't access their booking.

Be careful about who receives that request. The purchaser of a company booking may need to distribute it to the delegates. Sending a buyer a list doesn't prove that each person has approved their own information. Agree who is responsible for returning changes and how your team will connect them to individual registrations.

Use the account or communication process you already support. Don't promise a self service edit link unless it actually exists. If corrections arrive through support, require enough booking information to locate the right record without asking for unnecessary personal documents.

Distinguish routine attendance information from promotional messages in your communication setup. Badge confirmation should help someone attend the conference they booked. Adding unrelated offers makes the message less clear and can create a separate consent question for your team.

Check a physical proof before releasing the batch

A file review can tell you that the name is present. It can't tell you whether the printed result is readable, whether a character has become an empty box, or whether the code still scans when the badge is inside its holder.

Ask for proofs using the actual production equipment, materials and import process. Include the difficult records you identified during cleanup, such as a long name, an accented name, a non-Latin script where applicable and a missing optional field. Choose from your real registration data with appropriate access controls, rather than sharing extra personal information for convenience.

Check that empty fields disappear as expected and that no template label prints in their place. Confirm the complete name survives the layout. If a field doesn't fit, resolve the display treatment with the attendee where necessary rather than silently chopping off the end.

Then test the credential against the system staff will use at entry. Make sure a reprint process doesn't grant another admission accidentally, and confirm how staff recognise an invalid or already used ticket. Badge production and admission control need to agree.

Our conference badge design guide covers the presentation decisions. At this stage, your approval is about whether the agreed information and credential survive the real production process. Keep a record of the proof version you approved.

Control what changes after the print deadline

Your print deadline creates a production version. Registrations can still change afterwards, so decide how those changes reach the people producing and distributing badges. Otherwise, a cancellation can exist in the ticketing platform while its badge remains ready for collection.

Maintain one authorised change list connected to the original identifiers. Record whether each change requires a new badge, withdrawal of an old badge, a corrected field or a check at collection. Include the approval and completion status so your team can tell a request from a finished correction.

Ask the printer how it handles an updated file before sending one. Replacing a complete batch and importing a short list of changes can have very different effects. Confirm which process you are using, and check the resulting records instead of assuming a familiar filename means the update worked.

When a changed record has already produced a badge, follow it through to the physical item. Update the collection instructions and remove the superseded badge from circulation. A corrected database entry won't stop a volunteer handing over an obsolete badge from a box.

Keep late sales in the plan too. Staff need a supported way to check the current ticket, collect the required display information and issue the correct badge. Printing the original batch shouldn't force you to close registrations earlier than your event actually requires.

Use a short acceptance check for every production batch

Before you release a batch, compare it with the source export and the decisions made since that export. Account for records excluded from printing, records held for clarification and records approved for production. Those groups should explain what happened to the source registrations without unexplained additions or losses.

Check that the file contains the expected columns and that the receiving system uses each one for the agreed purpose. Inspect the beginning and end of the import as well as records with unusual characters. Confirm that no filter hid unresolved rows when somebody saved the file.

Ask the approver to check a few decisions against their evidence. Can they find the confirmation behind a substitution? Can they explain why a possible duplicate stayed in the batch? Can they trace a rejected print row back to its registration without searching by name alone?

Then record the exact approved filename or version, its creation time and who accepted it. Ask the supplier to acknowledge that same version before production starts. If something changes afterwards, use the agreed update process. A casual message saying "use the latest list" leaves too much room for somebody to print the wrong attachment.

Give the registration desk a way to resolve exceptions

Even a carefully checked file won't eliminate every correction at arrival. A delegate may change jobs after the deadline, lose a badge or discover that their company administrator entered the wrong name. Plan where those requests go before the main queue starts moving.

Keep routine collection simple, with a separate route for cases that need investigation. Staff should be able to locate the registration by its supported identifiers and see the current status. Limit personal information to what their role needs, and tell them who can authorise a substitution or access change.

For events using Loopyah, ticket check-in lets authorised door staff scan QR tickets from their phones. Keep that admission check connected to the current ticket. A printed name badge is useful identification inside the conference, but your team still needs to validate the entitlement behind it.

Confirm the badge printer's role separately when you choose the process. Don't assume ticket scanning includes badge production, or that correcting the print supplier's file updates the ticketing record. Test the handoff you will actually run.

Give desk staff a short set of approved responses for common problems. Include who can change a display name, who can replace a missing badge and how an access dispute gets resolved. People work more consistently when the next action is clear and someone is available to make the difficult decisions.

Keep the correction record useful and proportionate

After production, you should be able to explain why a record changed without reconstructing the answer from personal inboxes. Keep the original value, approved replacement, affected identifier, decision date and person who approved it where your process requires that history. Restrict access and apply your retention policy.

The Information Commissioner's Office's accuracy guidance says organisations should take reasonable steps to keep personal data accurate and deal with inaccuracies. It also discusses making the source and status of information clear. For a conference team, that distinction helps separate an attendee's confirmed correction from an unverified suggestion.

Once badge collection is complete, reconcile unresolved cases and retire working files according to the purpose and retention arrangements you agreed. Ask suppliers to complete their part too. A finished print job doesn't justify leaving attendee exports accessible to everyone who helped during setup.

Finally, keep a short record of what caused the cleanup work. If most problems came from unassigned company tickets, fix that booking process before the next conference. If characters broke during import, test the next export earlier. The useful improvement is preventing the same avoidable correction from reaching your registration desk again.