We benchmarked small-footprint scanners with OCR to speed DD214 intake, and a Fujitsu ix1600 plus ABBYY reduced manual entry by 38% across 200 files in a Cleveland RO pilot last month. If you’ve built a capture workflow at the unit or county level, what hardware/software combo holds up for chain-of-custody and audit trails, and did it move your turnaround KPIs enough to justify a staffing or funding shift?
We run an iX1600 into an ABBYY watched folder with a barcode cover sheet, which auto-indexes the DD214 and writes an immutable PDF/A plus a SHA-256 checksum to a WORM share, so chain-of-custody passes audit without extra steps. That bumped our intake turnaround about 30% at the county level, close to your “38%,” and the quick win was letting the clerk scan to that single preset destination. Minor caveat: ScanSnap Home’s logs are weak, so we lean on ABBYY’s job log and Windows file auditing for the trail.
Quick win: fi‑7160 + ABBYY with a QR cover sheet tied to case ID, pushing PDF/A‑2b to S3 Object Lock and logging a SHA‑256 in metadata + CloudTrail; cut our DD214 intake about 30% and kept chain‑of‑custody tight — like a time capsule you can’t pry open. Caveat: disable aggressive auto‑contrast in the driver or it washes out stamps; @vleonard60 your checksum idea pairs nicely with an RFC 3161 timestamp.
In our county shop, the iX1600 + FineReader mirrored your “38%,” but the bigger win was enabling patch‑code separation and a regex check on SSN and discharge date before commit; bad reads loop back to an exception queue instead of polluting the index. For retention and provenance, we push PDF/A‑2u into a SnapLock volume with immutable snapshots and Windows Advanced Auditing on the drop share; cheaper than S3 for us and passes our state records audit (docs: https://docs.netapp.com/us-en/snaplock/). If you’re dealing with carbon copies, , bump those to 600 dpi grayscale with VRS deskew, then downsample on export — saved us a bunch of rescans.