Two correct numbers, one wrong field
Picture a fictional supplier bill with a single goods row. Its AMOUNT cell shows ₹1,000. The summary shows ₹180 tax and a payable total of ₹1,180. Assume that tax treatment only for the illustration; the point is the role of the two amounts.
If the row's ₹1,000 is read into a field that means tax-inclusive line total, the source number was copied correctly and interpreted wrongly. Reading accuracy and field meaning have come apart. A clearer scan will not fix that if the software still assigns the same role.
I would begin with the tax summary. It often shows whether the amount at the right of the table is before tax, after tax or something you cannot establish. The header word alone is not enough. Suppliers use Amount and Total in different ways.
A net line amount excludes the line's tax; a gross line amount includes it. Supplier headers do not use those words consistently. Read the column alongside the printed tax and summary before assigning its role. If no reliable inclusive line total is printed, an optional field can remain empty rather than acquire a calculated value.
Both figures can be right. Putting the first into an inclusive field is not.
The visual uses one row because the document relationship is easy to see. Do not extend that convenience to a multi-line, mixed-rate invoice. A grand total does not establish how inclusive values belong to individual lines.
Find evidence of the column's role
Read the complete heading. “Amount before tax” is useful evidence. A bare AMOUNT is less explicit. Look for a separately printed GST column, a taxable subtotal and how the supplier labels the final payable figure.
Then inspect the row boundaries. A scan may glue the last goods amount to the first tax amount, especially when the table is narrow or tilted. The right number can end up on the wrong row before any net/gross question is asked.
A numerical equality is only a clue. If Amount happens to equal taxable value, that suggests a net role in a simple layout. It does not independently prove the meaning, especially when discounts, zero tax or separate charges are involved.
This is where the packing and freight footer complicates a neat example. The final invoice amount may include a charge that is not part of any goods row. Dividing or spreading it across the rows creates a new allocation, not a faithful reading.
Keep a short source note when the role is established. “AMOUNT before tax; GST shown separately in the summary” is more useful than “total corrected.” Someone else should be able to look at the same page and see why the field was handled that way.
When the label is cut off, request the complete page. It is better to leave the role unresolved than to apply a convention from the previous supplier. The person reviewing the scan does not gain evidence just by looking at it for longer.
Empty is different from missing required evidence
Some invoices print a line's taxable amount and tax but no inclusive line total. A data model may allow that inclusive total to be empty. That can be an honest record: the document did not supply that optional figure in a usable form.
That is different from a missing required taxable value or line tax. A workflow cannot erase required evidence to make validation pass. Understand which field is optional before using “not printed” as an explanation.
It is also different from calculating an inclusive amount and claiming it was extracted. ₹1,000 plus ₹180 is easy arithmetic. The result's provenance still matters. A calculated number should not quietly become a printed source value.
For EntryLedger, a populated line_total is checked as inclusive taxable value plus line tax, under the existing arithmetic tolerance. A null line_total remains optional. This is the shipped invariant, not a claim that the extractor perfectly interprets every vendor layout.
An experimental source-policy path can recognise a narrow net-role situation and abstain from an optional inclusive field. That path is off in production. I am not presenting it as a live automatic fix. A net amount in an inclusive field can therefore require source review.
| What the source establishes | What not to do |
|---|---|
| Net amount with separately printed tax | Call the net figure tax-inclusive |
| No printed inclusive line total | Invent one and label it extracted |
| Unclear column role | Choose the role that makes arithmetic close |
| Missing required tax evidence | Delete the requirement to obtain a pass |
Review the meaning, then the export
In the review screen, compare the fields against the source page. Read the line and the summary together. If you correct a field, make the correction explicit. Human confirmation is a decision on the reviewed record, not a hidden source-repair operation.
Use the total-mismatch checks after the field meanings are understood. Arithmetic can then test a coherent interpretation. It should not be used to select an interpretation from several unsupported possibilities.
On a mixed invoice, do not create a combined rate merely because the summary contains one overall tax number. The mixed goods and services discussion makes the same point about respecting distinct source rows.
The destination format also matters. A column called Amount in a CSV may not have the same semantics as a field called TotItemVal in another schema. Read the export contract rather than matching names by appearance. The format guide is a starting point, not a guarantee that every downstream mapping is qualified.
Tally XML remains a preview. Preparing and downloading a balanced file does not establish its actual import result or GST-report treatment. Check the relevant Tally import documentation and keep the qualification boundary visible.
The practical habit is small: when a right-edge number looks wrong, ask what it means before changing it. A field can contain the correct digits and still tell the wrong story.
- EntryLedgerShipped arithmetic validation
Populated inclusive line totals must close within the product tolerance; empty optional fields are a different case.
- EntryLedgerReview and preparation
Experimental net-role normalization is not enabled in production.
- Tally HelpOfficial import help
Check destination field meanings. Tally import/report qualification remains unverified.
Does AMOUNT always mean tax-inclusive total?+
No. Suppliers use that heading for different roles. Read the full heading, printed tax and summary together. A net amount copied into an inclusive field can contain the correct digits while expressing the wrong meaning.
Can an inclusive line total be left empty?+
In EntryLedger, line_total is optional when absent. That does not make required taxable value or line tax optional. Leave an unsupported optional value empty rather than calculating a replacement and pretending the invoice printed it.
Does equality with taxable value prove an amount is net?+
No. Equality is a clue, not independent source evidence. Zero tax, discounts and layout ambiguity can make simple comparisons misleading. Establish the column role from the document, or keep the question open for review.
Is automatic net-role normalization live?+
No. The experimental source-policy normalization is off in production. The shipped inclusive line-total check still applies to populated values. Review a conflicting reading against the source instead of assuming the software will silently reinterpret the column.