The supplier sends a three-page PDF. Page 1: tax invoice for ₹2,80,000, 5 tonnes of TMT. Page 2: delivery challan, same supplier, same date, lists the 5 tonnes as goods moved but not yet invoiced. Page 3: weighment slip. You scan the PDF. The system splits three pages. Page 1 exports as a purchase. Page 2 exports as a purchase. Page 3 exports as a purchase. Now Tally thinks you owe ₹5,60,000 for 10 tonnes. You bought 5.
Factory AP bundles are messy. The supplier staples the tax invoice to the challan. The weighment slip sits in the middle. Sometimes there is a lorry receipt from the transporter. Sometimes there is a credit note from last week. The photocopy pile does not sort itself. That is why page classing exists. It is also why page classing is not enough.
invoice, duplicate, challan, lorry, or other. The vote is a keyword check on already-extracted text: "tax invoice," "delivery challan," "lorry receipt," "office copy." No model call. No extra cost. But it is not a classifier trained on your paper. Ambiguous pages should go to review.
The five labels
Credit notes are not in this list. They may slip as invoice. Bake-off them. See credit notes.
How it fails
Challan page has "delivery challan" in 8pt. OCR reads it. pageclass votes challan. The row does not export. That is the correct failure.
Challan page has "tax invoice" in the header because the supplier used the same template for both. OCR reads "tax invoice." pageclass votes invoice. The row exports. That is the wrong export. The clerk should have seen the page number and the title. We did not.
Lorry receipt has "vehicle no" and "consignment note." pageclass votes lorry. The row does not export. Correct. But if the lorry receipt also carries a GSTIN and amounts (some do), the gate may pass GSTIN and arithmetic. If the row exports, that is a product bug. Score it.
What to do in a bake-off
Put a three-page bundle in the 500 scans. Page 1: tax invoice. Page 2: delivery challan. Page 3: weighment slip. Score: did page 2 export as a purchase? If yes, that is a miss. If page 3 exported, that is also a miss. If only page 1 exported, page classing worked.
Put a two-page bundle: tax invoice plus credit note. If the credit note exported, that is a miss we already admitted. See credit notes.
Put a single page that is a lorry receipt with a GSTIN. If it exported, the gate passed GSTIN on a transport document. That is a different class of miss than "wrong voucher type." Score it separately.
Meter
Three pages is three pages. ₹1.40 per page. The meter does not care that page 2 is a challan. That is honest billing. If you want to skip non-invoice pages in the meter, that is a product conversation, not a blog promise.
What we do not do
We do not classify credit notes. We do not classify proforma invoices. We do not classify GST challans issued under Section 31(3)(d) (tax on movement without supply). Those are product changes with tests. This page is what ships today. The most common honest challan is job-work: your goods out and back with no sale.
- EntryLedger
extraction/pageclass.pyinvoice, duplicate, challan, lorry, other. Keyword vote, no model.
- EntryLedgerCredit notes
Not in pageclass today. Known hole.
Does it detect challans?+
Yes, when the keywords fire. If the page says "tax invoice" instead, it may vote invoice. Review.
Credit notes?+
Not as a named class. They may slip as invoice. Bake-off them.
Lorry receipts with GSTIN?+
May pass GSTIN and arithmetic. If so, that is a miss. Score it.