Knowing you scanned every page

Almost every scanner failure announces itself. A jam stops the machine, a smear is visible, a crooked image looks crooked. The exception is a double feed: two sheets travelling as one, of which only the outer face was ever read. The result is a file that is complete, clean, correctly named and missing a page, with nothing in it indicating that anything went wrong.

The failure with no symptom

The output is not damaged, it is short. A damaged scan invites inspection. A short batch does not, because every image in it looks right. You would only notice by knowing how many items went in, and by the time you are looking for a specific receipt the paper is usually gone.

Two situations produce it. The ordinary one is a separation failure: the pad or counter-roller that should hold back everything under the top sheet stops doing so, usually because it has worn smooth, and takes a second sheet along. That is the wear pattern in scanner cleaning and consumables — a device that starts multi-feeding is more often reporting a finished rubber part than a fault.

The other is paper that is genuinely stuck together: static on thermal slips, a spill, or two receipts folded inside each other in a pocket for a month. No separation mechanism helps with that, because the two sheets are behaving as one by any measure the device can take.

How a device can tell

There are three arrangements, and which one you have decides how much you compensate manually.

• A thickness or gap sensor. The device measures something crossing a gap in the paper path and notices a reading that corresponds to more material than one sheet. This is the arrangement that actually works, including on paper that is stuck together, because it measures the paper rather than inferring from behaviour.
• Length comparison. The device knows how long the item should be, or how long the previous items were, and flags a page whose measured length is inconsistent. This is close to useless on receipts, because receipts genuinely vary in length by an order of magnitude within one batch, so there is no expectation to violate.
• Nothing at all. Very common on small, portable and single-purpose devices, where the sensor is one of the first things removed. Not a defect, just a design point — but the whole burden then falls on you.

If your device has a detection setting, find it and leave it on. Its failure mode is a false alarm rather than a silent loss, which makes it cheap to run at maximum sensitivity.

What the device does when it detects one

Detection and response are separate choices. Some drivers stop the transport and hold the paper, so you re-feed and continue. Some complete the page, flag it in a log, and carry on. Some show a warning that vanishes when the batch finishes — and a warning you did not see is equivalent to no warning. If the driver can be set to stop rather than notify, stop is the better setting for receipts: it converts an invisible loss into a visible interruption, and interruptions get noticed. Find out too whether the flagged page reaches the output or is discarded; both behaviours exist and they need different responses.

Counting is the fallback, and it has to be cheap

Without a sensor, arithmetic is the only defence. It works, but only if the count is easy enough that you actually do it — a verification step that takes real effort gets skipped on the third batch and forgotten by the tenth.

What makes it cheap is batch size. A dozen slips can be counted at a glance on the way in, and the resulting page count read off the driver afterwards. Two hundred cannot be counted reliably at all, so the honest options are to split the stack or to accept that you are not checking. Small batches fail better in every other respect too: a jam costs less to recover from, and mixed-width stacks misbehave more the larger they get, for the reasons in why receipts jam.

The count needs something to be compared against. If the driver reports pages captured per batch, that is the comparison; if it does not, the file is — one multi-page document per batch puts the page count in front of you in any viewer, while one file per slip means counting files. Either way it is arithmetic on physical items, not a judgement about images.

Blank-page discard breaks that arithmetic outright, because pages are being removed on purpose. Running both means you need the discard count as well as the capture count, which is part of why duplex scanning, and what blank-page removal deletes argues for keeping that feature off on receipt batches.

Things that are one item and two pages

A few mismatches are not double feeds, and recognising them saves hunting for a fault that is not there.

• Stapled or clipped slips. A receipt stapled to a card slip is two sheets held together deliberately. Separate them first — never expect the feeder to resolve it, and never send metal through a transport.
• Folded slips. A slip folded in half is two thicknesses at the fold and one elsewhere, which legitimately trips a thickness sensor. Flatten first.
• A slip that tore in the path. Genuinely two items where one went in, so the count goes up rather than down.
• Receipts printed on both faces, where a duplex profile yields two pages from one slip and a simplex profile one.

What to check before you trust a batch

Do this when a device arrives, and again whenever it starts feeling unreliable. Feed a batch you made deliberately hostile — some slips with a little static, one pair pressed together, a mix of widths — and see whether the device notices anything. Then compare items in against pages out. That tells you what your detection is worth rather than what the specification claims, and it is the principle behind testing a scanner with your own paper.

If the device notices nothing, that is useful to know rather than a reason to replace it. It means your batches need to be small enough to count.

Whether a missing item matters, and what obligation you have to hold the record at all, depends on rules that vary by country and by the kind of entity keeping them. That question belongs with your own tax authority or an accountant in your jurisdiction.