Key takeaways
- Scan-data programmes are optional agreements between a store and a tobacco manufacturer.
- Enrolled stores send a weekly, transaction-level file of tobacco sales, with every discount on its own line.
- Most rejected data comes from missing store details, discounts folded into prices, wrong units and unknown UPCs.
- Your agreement, not your POS, decides what you are paid. The POS decides whether your data is clean.
If you sell cigarettes, you have probably been offered a scan-data programme by a manufacturer representative: send us your sales data every week, and in return get access to promotions and incentive payments. The money can matter, and so does the data quality. This guide explains how it works.
What is tobacco scan data?
Tobacco scan data is the transaction-level record of your tobacco sales, sent weekly to a manufacturer programme you have joined. Each line describes one item sold: which product (by UPC), how many, at what price, with which discounts, when, and at which store and register.
Manufacturers use it to see what actually sells at the counter, to fund promotions such as multipack offers and loyalty prices, and to calculate the incentives they pay participating stores.
How do scan-data programmes work?
The broad shape is the same across the large programmes, although each manufacturer sets its own details:
- You enrol. You sign the programme’s retail agreement and choose which categories you take part in.
- You run the programme’s promotions. For example a price per pack when a customer buys two, or a loyalty price for registered adults.
- You report weekly. Every week, you send a file of all qualifying tobacco transactions in the format the programme specifies.
- The programme validates the data. Rows that are incomplete, late or inconsistent can be rejected.
- You are paid according to the agreement, typically monthly, for compliant data and promotions.
Requirements change over time, and programme documents are periodically revised. Always work from the current requirements document your representative gives you.
What does a weekly file contain?
The exact fields differ by programme, but most files carry the same groups:
| Group | Typical fields |
|---|---|
| Store profile | Store name, address, the account or store number assigned to you |
| Transaction | Date, time, transaction ID, register |
| Item | UPC, description, quantity, unit of measure (pack or carton) |
| Price | Selling price, final price after discounts |
| Promotions | Multipack discount, manufacturer discount, retailer discount, loyalty ID where used |
| Category | Cigarettes, smokeless, cigars, vapor, as the programme groups them |
Files are usually delimited text (pipe or comma separated) or another format the programme accepts.
Why do scan-data rows get rejected?
From what owners tell us, the same five problems cause most rejections:
- Missing store details. The file must identify the store exactly as enrolled.
- Discounts folded into the price. If a buy-two discount is recorded as a lower price instead of a separate discount, the programme cannot see the promotion it funded.
- Packs and cartons mixed up. Receiving cartons and selling packs is normal; reporting a carton as one unit is not.
- Unknown or mis-keyed UPCs. A product typed in by hand under a made-up code cannot be matched.
- Late or missing weeks. A week not sent is a week not counted.
What is the data-quality checklist?
Print this and go through it before you enrol, then once a month:
- Every tobacco item in the POS has its real manufacturer UPC.
- Each product has the right selling unit (pack) and purchase unit (carton) with the right count.
- Programme promotions are set up as automatic discounts with start and end dates, not as price changes.
- Discount types are separate: multipack, manufacturer, retailer, loyalty.
- The store profile in the export matches your enrolment exactly.
- Voids and refunds of tobacco items are recorded properly, not by deleting lines.
- Someone owns the weekly export and has a calendar reminder.
How does the POS help?
On GetConvenienceStorePOS, US stores on Full Shift and Multi-Store get scan-data exports. Every tobacco sale is recorded with its discounts on their own lines, units are checked against your product setup, unknown UPCs are flagged, and the weekly file is built from your programme’s current requirements and kept on file.
Programme rules, payments and formats are set by each manufacturer. We do not decide what you are paid; we help make sure your data is complete.
Questions to ask before you enrol
- Which categories does the programme cover, and must competitive products be reported too?
- What is the weekly deadline, and how is the file delivered?
- Which promotions must I run, and how are they recorded?
- How are payments calculated, and when are they made?
- What happens to a week of rejected rows?
Sources
- Manufacturer scan-data retail reporting requirement documents (as provided by programme representatives); historical versions reviewed October 2026.
- Vendor and industry guides on scan-data programmes, October 2026.
General information for store owners. Your programme agreement governs.
The Store Desk · Retail operations editors, GetConvenienceStorePOS
The Store Desk is the team behind onboarding and support for GetConvenienceStorePOS. Every guide on this site starts from a question an owner asked us during a demo or a setup call: how to card customers, why a lottery settlement will not balance, what a scan-data file must contain, how to close a shift without an argument. We cite the rule or the source we rely on, date every article, and correct it when a rule changes. Guides are general information, not legal advice; your state licence and your manufacturer agreements are the final word.
Expertise: convenience store operations, age-restricted sales, lottery reconciliation, tobacco scan data, cash handling, POS setup
