Going paperless under the Food Act 2014: what verifiers will and won't accept

Walk into any café, restaurant, or aged-care kitchen in New Zealand and you'll find the same thing on the back-of-house wall: a clipboard. Pages of temperature logs, cleaning ticks, delivery dockets, all written in biro, all going slightly damp.

It works. Tens of thousands of operators have passed verifier visits on paper. But paper is a tax — on your time, your retrieval speed, and your verifier's patience — and the question we get asked more than any other is some version of: "Can I actually ditch the paper diary? Will the verifier accept it?"

Short answer: yes. The Food Act 2014 doesn't mandate paper. The current Simply Safe & Suitable template (S39-0005, effective 30 April 2026) explicitly contemplates digital records. Verifiers across the country prefer digital — when it's done right. This post explains what "done right" means, what the law actually says, and where most operators trip up when they try to switch.

What the Food Act actually says about records

You will not find "paper" or "digital" anywhere in the Food Act 2014. The Act and its regulations are technology-neutral. What they say is:

You must keep records of your food safety activities.
The records must be available to the verifier on request.
You must keep them for a minimum of 4 years (Food Act §65).
They must be accurate, complete, and reflect what actually happened.

That's it. Paper, digital, hieroglyphics — the Act doesn't care. What matters is that the records exist, are accurate, are retrievable, and can be trusted.

What S39-0005 says about digital records

The new Simply Safe & Suitable template (in force from 30 April 2026) is where MPI gives operators concrete guidance on what digital looks like. It identifies four properties a digital record must have to count:

Server-timestamped. The time the record was made — not the time it claims to have been made — has to be captured by the system, not by the user typing in a date.
Attributed. Every record must be linked to a named, identified staff member. Not "morning shift," not blank.
Immutable. Once a record is committed, it cannot be silently edited. Corrections are made by creating a new record that references the original — and the original stays visible.
Exportable. The verifier must be able to leave with the records (CSV, PDF, or print) for their own audit file.

These four properties are the thing. If your digital system has them, you have a compliant record. If it doesn't, you're worse off than paper — because a digital record without these properties can be tampered with, and a verifier who suspects tampering will mark you down harder than they would for a missing paper entry.

Why verifiers actually prefer digital — when it's done right

We talk to verifiers regularly. The honest summary of their position:

They like paper because it's familiar. Most verifiers have been doing this for years and they know how to flip through a diary fast. Digital systems they don't know slow them down.

*They love a good digital system because it makes their job faster.* A verifier visit on paper takes 60-120 minutes of cross-referencing diary entries against the FCP. The same visit using a search-by-date-and-module digital system takes 20-30 minutes. The verifier knows this. They're not paid by the hour; they want efficient visits.

*They hate a bad digital system more than they hate paper. Excel spreadsheets that anyone can edit. Photos of paper logs uploaded to Dropbox. Apps with no audit trail. These are worse than paper because they create the appearance* of records without the substance.

So the choice isn't paper vs digital. It's paper vs good digital. Bad digital is worse than paper.

What "bad digital" looks like (don't do this)

Three patterns we see from operators who tried to go digital and ended up in trouble:

1. Excel spreadsheets shared on Google Drive

The fail: any user can edit any cell at any time, with no log of who changed what. A verifier opens the file, sees a temp reading of 4.2°C on the 14th, asks "when was this entered?" and you can't tell them. Was it on the 14th? Or two days before the verifier visit?

This fails property #1 (server-timestamped) and #3 (immutable). Verifiers know about it and will mark you down.

2. Photos of paper logs uploaded to a folder

The fail: the photo is timestamped by your phone (a client clock you control), and the paper itself can be backdated. This is paper records in a folder, not digital records. You get the worst of both worlds — none of the retrieval speed of digital, none of the simplicity of paper.

3. Apps that don't have an audit trail

The fail: the data is in the cloud, sure, but there's no immutable history. If you tap a temp reading and change it, the old value is gone — no record that it existed, no who-changed-it-when. A verifier asking "when was this corrected?" gets a shrug.

We've seen multiple "food safety apps" on the App Store that fall into this trap. They look modern. They store everything in the cloud. They've thought hard about UI. But they let any user edit any record at any time, with no audit trail. They pass internal use; they fail verifier scrutiny.

What "good digital" looks like

A compliant digital food safety system needs:

Records committed to a server, not just the user's device. Server takes timestamp, user identity, and assigns an immutable ID.
An immutable history. When a record is corrected, the original remains visible with a flag — "corrected by [name] at [time]". The new record references the old one.
A user identity per record. No anonymous entries. No shared logins.
Export to PDF/CSV. Verifier gets a static copy of the records, exactly as they appeared at the time of export.
Offline capture, server-side commit. Mobile staff log records even with no signal — but the commit happens when the server receives the data, with the server timestamp, not the device clock.

That last point is the one most operators miss. A staff member in a walk-in cooler with no WiFi should be able to log a temperature. But when their phone reconnects, the server has to be the source of truth for "when did this record become part of the FCP." The system architecture has to separate "when the staff member recorded the value" from "when the system committed it" — and the verifier looks at the latter.

The transition — how to switch without losing history

If you're on paper today and want to switch to digital, the migration looks like:

Step 1: Keep doing what you're doing

You don't stop the paper diary on day one of the digital system. Run both for the first 30 days. This is how you prove to your verifier (and yourself) that the digital system captures everything the paper one did.

Step 2: Archive the paper

Boxes of completed pages, labelled by date range, stored somewhere dry. You have to keep them for 4 years anyway. Don't shred them.

Step 3: Tell your verifier

When you next have a visit booked, send them an email a week before: "We've moved to a digital system. Here's a sample export. We've kept paper running in parallel for the first 30 days for continuity."

Verifiers will appreciate the heads-up. Many will ask you to walk them through the digital system at the start of the visit. Half an hour of upfront walkthrough saves the verifier guessing and you proving.

Step 4: Set the cutover date

After your first clean digital verifier visit, you can stop running paper in parallel. Most operators we see do this 60-90 days into digital.

Step 5: Keep the paper archive

For 4 years. Even though you've moved on. The Food Act 4-year retention rule applies to all records — paper records of historical compliance are still records.

Common worries — and the actual answers

"What if I lose internet?"

A well-designed mobile food safety system writes to local storage first, then syncs. You can log a temp in a walk-in cooler with steel walls and no signal. The record is captured on the device. When you walk back into WiFi range, it commits to the server. The server takes the commit time as the official record time. (This is exactly how Kai Safe works.)

"What if my phone breaks?"

The records are on the server, not the phone. The phone is just the input device. Replace the phone, log in to the new one, history is all there.

"What if the company goes bust?"

This is the most important question, and one almost nobody asks. The answer must be: you can export everything, at any time, as a static PDF + CSV bundle, and that bundle counts as your records for the 4-year retention requirement.

If a vendor can't tell you exactly how to export, walk away. We provide a one-click full-archive export in Kai Safe — it dumps every record, every corrective action, every photo, every staff training cert, as a single ZIP with PDFs and CSVs. You can hand that to a verifier even if Kai Safe disappears tomorrow.

"What if a staff member quits and I lose their login?"

The records they made are attributed to them — by name, in the immutable history — forever. Their leaving doesn't erase the records they created. Their login is deactivated, but the trail of work they did stays.

"My verifier said they want paper"

Most often this is the verifier guessing what's easier for them, not a legal requirement. Some verifiers genuinely prefer paper because they're slow with tech. The way to handle this is to export a paper bundle for the visit — print the PDF, give it to them on a clipboard, watch them flip through. They get paper; you get digital.

A growing number of MPI verifiers actively prefer digital because of the verifier portal — where they can search across all records by date, module, or staff name, in their own browser, before the visit.

How Kai Safe handles the four S39-0005 properties

In Kai Safe:

Server-timestamped: every record's created_at is stamped by our API on the server, not by the device. The device sends a separate client_recorded_at field so we can show both — "logged at 9:02 (recorded by staff at 8:55)".
Attributed: every record requires a logged-in user. Shared logins are blocked at the architecture level — each staff member gets a PIN, attached to their identity.
Immutable: UPDATE is never performed on compliance records. Corrections create a new record with is_correction_of referencing the original. The verifier sees both.
Exportable: one-tap PDF export per period, plus the verifier portal (a PIN-protected link they open in a browser, with full CSV download).

Try the verifier portal sample pack — you can see exactly what your verifier would see in their browser, right now.