Cover the headings on a supplier invoice for a moment. Look only at the first row. You might see a serial number, an HSN code, a quantity and a unit price before you reach the amount. Several numbers. Different jobs.
Now imagine an extractor puts the row's serial number into Qty while copying the printed taxable value and tax correctly. The invoice totals still balance. The extracted quantity is wrong. This is a fictional example, but the failure is quite ordinary: a number was recognised and assigned to the wrong column.
Quantity transcription asks whether the extracted quantity matches the quantity printed on the invoice. Purchase matching asks whether the billed quantity agrees with the purchase order and goods receipt. They are separate checks. Correct totals do not prove correct transcription, and a correctly read invoice can still overstate what arrived.
The first number isn't necessarily the quantity
I would put the heading row beside the disputed line before touching the field. On a narrow photocopy, “Sr.” may be clear while “Qty” has faded. The cleanest number attracts attention. It is not necessarily the right number.
The invoice might print 1, an HSN, 27 NOS, ₹100 and ₹2,700. In our example, ₹486 GST gives a ₹3,186 total. Copying the money correctly while extracting quantity 1 leaves a plausible-looking record with the wrong physical meaning. Those prices and taxes are illustrative, not an assertion about any actual item or applicable rate.
A correct amount does not tell you which column the reader used for quantity.
A second row helps you understand the layout, but it is not permission to fill a missing field. If the first column runs 1, 2, 3, that suggests serial numbers. Check its label and position. The supplier may also have quantities 1, 2 and 3, so the sequence by itself is not proof.
Thermal bills make the problem different. A description can be followed by a quantity-times-price expression instead of a ruled table. A multiplication mark might look like a letter; part of the expression may fall onto the next line. Read that physical expression before treating its first digit as a quantity.
Why I won't solve Qty from the amount
Dividing taxable value by unit price feels efficient. Sometimes it even returns a tidy integer. It still answers a different question: what quantity would produce this amount under your assumptions? It does not show what quantity the supplier printed.
Discounts can break the assumed relationship. So can a price per hundred, a pack size or a charge included in the line. Weight and piece counts may sit on the same row. A source field cannot safely be replaced by a calculation merely because the result looks clean.
That matters for a manufacturer. A row for 27 pieces is not interchangeable with a row for 27 kilograms. The payable rupees can be identical while the inventory implications differ. Our separate unit and UQC guide takes that boundary further.
The same warning applies to Rate. A supplier's Rate column may mean rupees per unit; a tax field named rate means a GST percentage. Copying ₹100 into a percentage field creates a different failure from reading Qty incorrectly. Review the roles rather than arguing about whether the OCR engine read the characters accurately.
Arithmetic is still worth doing. The invoice closure check catches inconsistencies in the amounts it compares. It is not a universal guarantee that every optional or physical field was read exactly. Giving it that job hides the questions it was never designed to answer.
Read the source, then open the GRN
Start the review with the complete source page, not an isolated string. Find the Qty heading, the relevant row and its printed unit. If the heading is on page one and the line is on a continuation page, keep both available. The context is part of the reading.
Compare the extracted field with that source. If it differs, correct the extraction explicitly. Keep any separate commercial dispute separate. You should be able to say “the bill prints 27; the record now says 27” without implying that 27 pieces actually arrived.
Only then move to PO and GRN matching. Perhaps the PO ordered 30 and the GRN recorded 25. The invoice's 27 is now accurately transcribed, but the payment or receipt decision still needs purchase and stores. AP should not edit the invoice's quantity to 25 just to make the match screen green.
Record the supplier claim or credit-note request outside the original transcription. The paper says what it says. A commercial settlement can change what you owe without changing what the original paper printed.
Where a value is unreadable, obtain a clearer copy. Increasing confidence is not the same thing as recovering evidence. A clerk looking at the same blur as the model should be allowed to leave the issue unresolved rather than confirm a guess.
The review card I would keep
Make the source reference specific enough that the next person can repeat your check. “Qty checked” is weak. “Page 2, row beginning spacer bush; Qty column prints 27 NOS” is useful. It directs the eye and keeps the decision bound to the document.
- Locate the printed heading and the physical row.
- Read the quantity with its unit and any price basis.
- Keep extraction correction separate from receipt or payment approval.
- Ask for a better source if the printed value cannot be established.
If two rows share the same HSN, use the description and position as well. HSN is not a unique row identifier. A correct quantity attached to the wrong repeated item is still a bad reading.
Be wary of moving through a long invoice by remembering the previous layout. The first supplier used the left column for Qty. The next uses it for item code. Familiarity makes you faster until it makes you wrong.
EntryLedger puts source review beside the extracted fields and uses checksum and arithmetic validation before automatic preparation. The experimental quantity-source guard is not enabled in production. I am not claiming this specific error is automatically caught on every scan. See what the shipped gate checks, then use the review screen for what it cannot establish.
Confirmation prepares an entry for export. It does not confirm that the factory received the goods, authorise payment or complete a Tally import. Those decisions belong to their own records and people.
On the next bill with a suspiciously neat quantity, look at the heading before reaching for the calculator. The answer might be printed one column to the right.
- EntryLedgerThe shipped validation checks
Amounts and checksum consistency are not proof of exact quantity transcription.
- EntryLedgerSource review and export preparation
Review is separate from physical receipt, payment approval and Tally import.
- Tally HelpTally import documentation
Downstream mappings and import results require their own verification.
Can wrong quantities survive balanced GST totals?+
Yes. An extraction can copy taxable value, tax and total correctly while assigning a serial number or another column to quantity. Arithmetic over the copied money does not independently prove that the quantity agrees with the source invoice.
Should I divide the amount by unit price to recover Qty?+
Not as a substitute for reading the source. Discounts, pack sizes and price bases can make that calculation misleading. It can prompt an investigation, but the field should reflect the printed quantity or remain unresolved until better evidence is available.
Does a correctly read quantity mean the invoice matches the GRN?+
No. Transcription establishes what the supplier billed. A PO and GRN comparison establishes how that relates to what you ordered and received. Keep a source correction separate from any commercial dispute, receipt adjustment or supplier credit-note request.
Does EntryLedger automatically source-check every quantity?+
No. The experimental quantity-source guard is not enabled in production. Use the source-first review flow where a reading is uncertain. Confirmation prepares the reviewed record for export; it is not goods-receipt acceptance or payment approval.