Daily classroom attendance with QR codes and Google Sheets

Taking the register is the most repeated administrative task in teaching. Five minutes a day, five days a week, thirty-nine weeks a year is roughly sixteen hours of calling out names — and it still produces a paper sheet that gets lost, or a spreadsheet someone types up in the evening.

This guide is written for an individual teacher setting this up themselves, without waiting for a school system, an IT ticket, or a procurement decision. Everything here works with a Google Sheet you own and a phone you already have.

Why does the free Google Form approach struggle in a classroom?

The standard advice is a Google Form with a printed QR code on the wall: students scan it, type their name, and submit. It is free and it genuinely works for some settings, so start there if it fits. The free Google Form method for QR attendance is set out step by step in the school guide.

In a real classroom it usually breaks for reasons that have nothing to do with the software:

• It needs every student to have a phone with data. In most year groups that is either untrue or unevenly true, and it is often against policy anyway.
• It is self-reported. A student can submit for an absent friend, submit twice, or submit from the corridor. If attendance is tied to safeguarding or funding, that is not a register you can defend.
• The queue runs at the speed of the slowest typist. Thirty students entering their own names is slower than one adult scanning them.
• A submission with no signal is lost, not queued. School wifi is frequently the weak link.
• One shared form means one timestamp stream, so separating period 1 from period 4 becomes a cleaning job every week.

Invert it: the teacher scans the students

Give each student a printed code and have the adult do the scanning. This single change fixes almost every problem above at once.

• The phone requirement lands on one adult instead of thirty children.
• Presence is witnessed rather than claimed.
• A duplicate scan can be flagged, so you notice a code being passed around.
• One code per class or session keeps periods cleanly separated with no post-processing.
• Throughput is roughly one student per second.

QR to Sheets is built for exactly this shape, and its QR attendance system for schools page covers the whole-school version, so read this section as interested but specific. You connect your own Google Sheet, create a scanner link, and open that link on your phone. Each scan appends a row. Nothing is installed, and if a cover teacher takes your class you send them the same link and it works immediately — no account, no setup, no explaining.

Hosted by Pip4:02

How do I scan student ID cards into Google Sheets?

If your school already issues ID cards with a barcode or a QR code on them, you do not need to print anything. Where a card has a code, it usually holds the student number as a QR code or a 1D barcode such as Code 128 or Code 39, and a phone camera reads it as it is, with no reprinting. Scan one card into a test row first and check the value matches the ID your school's systems use; some cards add a prefix or a check digit that is worth knowing about before the first real register.

On the free route a Google Form has no scanner of its own, so the number still has to be typed or pasted into the form. With QR to Sheets you open the scanner link and point the phone at each card: it reads QR codes and the common 1D formats (Code 128, Code 39, EAN, UPC and ITF), and the value lands in the Sheet exactly as encoded, leading zeros included. A worn or scratched card that will not read can be typed into the manual entry field.

What it costs, honestly

The free tier covers 300 scans in total, which is enough to trial the whole thing with a real class for a couple of weeks. Beyond that it is $7 per month for the device you scan with, with unlimited scans.

For a single teacher scanning their own classes, that is one device. Thirty students scanned twice a day, five days a week is roughly 1,200 scans a month, and the price does not move — you are paying for the phone, not the scans or the students. It is also small enough to be a personal decision rather than a procurement one, which for most teachers is the difference between doing it this term and never doing it.

Turning scans into a register you can report from

Keep the scan log untouched and build everything on top of it. In practice:

• Insert a pivot table with student as rows and date as columns, counting scans. That is your register grid.
• Anyone with a zero on a given date was not scanned. Treat that as the absence list rather than maintaining a separate one.
• For late marks, compare the scan timestamp against the period start time with a simple formula.
• For a termly summary, count scans per student and divide by sessions held.
• Never edit the log to correct a mistake. Add a correcting row instead, so the record stays auditable if a parent or a manager queries it.

Privacy, because this is data about children

Attendance records about identifiable pupils carry obligations under GDPR, FERPA, or your local equivalent, whichever tool you use. A few practical things make compliance easier rather than harder:

• Encode student IDs rather than names in the codes. A code found on the floor then reveals nothing.
• Keep the Sheet in a school-controlled Drive with explicit sharing, not a personal account, if your school provides one.
• Check what any third-party tool can actually access. A tool limited to the one spreadsheet you selected is far easier to justify to a data protection lead than one with broad Drive access.
• Decide a retention period for the raw log and apply it.
• Tell your data protection lead before you roll it out beyond your own class. It is a short conversation if you go in with the answers above, and an awkward one if you do not.

The same setup covers more than the register

Once the codes are printed and the habit exists, the same scanner handles the other things that quietly eat a teacher's time: device and textbook loans, club and detention sign-in, trip headcounts, exam room entry, and equipment checkout. Only the destination Sheet changes.

What happens when the same student gets scanned twice?

This will happen in your first week. A student joins the queue again because they were not sure it worked, you scan a desk label twice while walking a row, or a card is lying face up and gets read as you pass. The question is not how to prevent it but what you want the register to do about it, and there are only two sensible answers.

A scanner can refuse the second scan, or it can record it and tell you. Refusing looks tidy on the phone and costs you information: once a scan has been discarded you cannot tell it apart from a scan that never happened, and you cannot reconstruct what occurred if a mark is queried later. Recording it keeps the log complete and moves the decision into the spreadsheet, where it is reversible.

QR to Sheets does the second, so read this as one design rather than a universal rule. Scan the same value again within twelve hours and an amber badge shows the repeat count alongside the words "Saved anyway". By default both scans are saved and the repeat is flagged. If the repeat lookup is unavailable the scanner fails open, meaning the badge does not appear and you carry on scanning rather than being stopped mid-register. A link can be set to refuse repeats instead (Accept duplicate scans off), but that refuses a code for good, so a register reused every day should keep it on.

For a daily register this is usually a non-issue, because the pivot table you already built counts scans per student per date and a student with two scans still reads as present. If you want an explicitly deduplicated tab, wrap the log in UNIQUE or QUERY and leave the log itself untouched. The badge is more useful as a live signal than as a data problem: two scans of the same code in quick succession is worth looking up for.

Can I use one shared phone or tablet at the door?

Yes, and for a classroom it is often the better setup than scanning with your own phone. An old tablet propped at the door, or a spare phone on a stand, means the register is taken by whoever is standing there rather than by whoever owns the right phone. It also gets your own phone out of your hand at the exact moment a class is arriving.

A scanner link makes this straightforward because it is a public URL with no login. Open it once on the shared device, allow the camera, and bookmark it or set it as the home page so the next person to pick it up is already on the scanner. Because there is no account attached, there is nothing sensitive sitting on a device that lives in a classroom, and nothing to log out of at the end of the day.

• Bookmark the link on the shared device's home screen so nobody has to find the URL again.
• Keep the device plugged in. A dead tablet at 08:55 is the failure mode that ends the habit.
• Use one link per class or session so periods stay separated without any post-processing.
• The paid plan bills per registered device, so a shared tablet used by four teachers is one device, not four.
• Requires a reasonably current browser: Safari 16.4 or later, or Chrome 111 or later. An ancient spare tablet is the one case worth testing before you rely on it.

The same property is what makes cover so easy. A cover teacher does not need the shared device set up for them, because there is nothing personal in it to set up. They open the link, or pick up the tablet that is already on it, and scan. Setting up a QR check-in kiosk on a shared tablet covers the station in more detail.

What happens to the register when the wifi drops?

School wifi is the weak link in most classroom systems, and corridors and mobile classrooms are usually the worst of it. This is where the free Google Forms route fails hardest: a form submitted with no signal is simply lost, and the student who submitted it believes they are marked present. You find out at the end of the week, when the numbers do not add up.

A scanner link handles it differently. Scans are written to the device first, into a local CSV backup and a retry queue, and then synced to the Sheet when signal returns. You keep scanning the whole class with a dead connection and the rows catch up afterwards. The register you took is not at the mercy of the access point in the corridor.

The part worth understanding is what happens on retry. Each scan carries its own identifier, so when the queue drains and a scan is sent again after a partial failure it lands on the same row rather than creating a second one. That matters because the obvious naive fix for offline capture, retry until it works, is exactly what produces mystery duplicate rows a fortnight later.

Will the timestamps match my school day?

Only if the timezone is set correctly, and this is the single most common reason a late-mark formula produces nonsense. It is worth two minutes of attention on setup day because it is invisible when wrong: the rows arrive, the register looks fine, and only the lateness column is quietly incorrect by a fixed number of hours.

There are two separate traps. The first is the offset itself: if a scan is recorded in UTC and your school day starts at 08:40 local, every comparison against a period start is wrong by however far you sit from UTC, and wrong by a different amount either side of a daylight saving change. The second is subtler. If a timestamp is written as a raw ISO string, Google Sheets stores it as text rather than as a date. Sorting then goes alphabetical, filters by date range return nothing, and any formula that does arithmetic on it fails silently.

QR to Sheets writes YYYY-MM-DD HH:MM:SS in the timezone set for your workspace under admin settings, which Sheets reads as a real date-time. Set that once when you connect the Sheet. If you are building the register with a different tool, check the same two things: that the offset is your local one and that the column right-aligns as a date rather than left-aligning as text. If your times are already off, why Google Sheets timestamps show the wrong timezone walks through each cause.

• Set the workspace timezone before the first real register, not after you have a term of data.
• Check the timestamp column aligns right in Sheets. Left-aligned means it is text, and every date formula on top of it is unreliable.
• Build the late-mark formula by comparing the scan time against the period start, then test it against a scan you know was late.
• Re-check the first register after a clock change if your region has one.

Step by step

1. 1

   Print one QR code per student

   Paste your class list into a bulk QR generator and print the sheet. Encode the student ID if your school uses one, otherwise the name is fine. Tape each code inside the front of a planner, onto an ID card, or onto the corner of a desk.

2. 2

   Make a Google Sheet with one row per scan

   Not one row per student per day. One row per scan: timestamp, student, class. A register is a pivot table built on top of that log, and keeping the log append-only is what lets you fix mistakes later without destroying history.

3. 3

   Set up a scanner you open on your own phone

   You want something that opens as a web page, because anything requiring an install will not survive a school device policy and cannot be handed to a cover teacher.

4. 4

   Take the register by walking the room

   Scan each student as you pass their desk, or scan them at the door as they come in. Roughly one student per second, so a class of thirty is under a minute.

5. 5

   Build the register view once, reuse it forever

   A pivot table keyed on student and date turns the scan log into the grid you actually report from. Build it once in September and it fills itself in for the rest of the year.

Frequently asked questions