AUTO_EXPORTED or NEEDS_REVIEW. There is no "pretty sure" that still writes Tally.

The clerk opens the review queue on a Monday morning. There are 30 rows. Each row shows the scan crop on the left, the extracted fields on the right, and the reason for failure at the top. GSTIN checksum failed. Total does not match. Regime conflict. Missing buyer GSTIN. The clerk reads the reason, looks at the crop, confirms or corrects. The row exports. The rest of the queue follows.

This is not a failure state. This is the product. The gate blocked what it could not prove. The human confirmed what the gate could not know. The voucher that reaches Tally has been through both: the machine and the person. That is how nothing wrong reaches the books.

What straight-through means

Straight-through is the share of your invoices that pass all validators and export without a human touch. The rest go to review. Measured on your paper. Not a lab PDF. Not a vendor's sample. Your photocopies.

You pay ₹1.40 per page for everything the pipeline processes, including the rows that land in review. But the clerk's time on review is the honest cost of bad paper.

What review looks like

Keyboard-first. 1366x768. Scan crop beside the field. Reason string at the top. Confirm or correct. Export. Next row. The clerk does not need a mouse tour. The clerk needs to see the scan, read the reason, and decide. See review UI.

If the reason is "GSTIN checksum failed," the clerk looks at the GSTIN crop. If the scan is smudged, the clerk types the correct GSTIN from the paper. If the scan is clear and the GSTIN is wrong, the clerk asks the supplier. Either way, the row exports after correction.

If the reason is "total does not match," the clerk looks at the printed total and the extracted lines. If the lines add up to something different, the clerk checks the round-off row. See round-off. If the total is genuinely wrong, the clerk queries the supplier.

What happens if you approve everything

You can. The review UI does not stop you. But if you approve every row in review, you have bought a slider, not a gate. The gate's job is to block what it cannot prove. If the human approves everything, the gate's job was wasted. The voucher may still be wrong. The review note should say why it was approved.

If your process is "approve everything over 90% confidence," that is a slider. Confidence is not a validator. See Nanonets vs for why confidence scores are not arithmetic.

The audit trail

Every verdict stores: checks_run, failures, warnings, duration_ms. The scan is there. The reason is there. Who confirmed is there. If the CA asks "where did this GSTIN come from," the trail is: scan, crop, checksum, who confirmed. That is an audit trail. "92% confident" is not. That trail is also what the checker reads: two chairs, three lanes, one owned sentence.

The trail is in the validator log. It is not in a spreadsheet. It is not in a WhatsApp message. It is in the product. See audit trail.

Steady state

Your console shows straight-through, measured on your own paper. The rows in review are not a failure. They are the honest cost of bad paper. The gate caught them. A human confirmed them. The voucher is clean.

If the 15% is mostly new vendors, the mapping table is incomplete. Add them. If the 15% is mostly bad paper, the supplier needs better scans. That is a vendor conversation, not a product feature.