Error 1008: Sum of Line Items Does Not Match the Total

When Fatoora platform rejects your invoice with error code 1008, the message is telling you one specific thing: the sum of the line amounts inside the invoice does not equal the total declared in the totals element. The invoice is structurally sound, but it carries an arithmetic contradiction between what you wrote in the lines and what you wrote in the final field. This guide explains this one error in detail: what it means, where it comes from, how to pinpoint exactly where it occurs, and how to fix it and prevent it from recurring.

This guide is part of Qoyod’s e-invoicing guide, and it complements the guide on ZATCA e-invoicing errors and the guide on Validation Errors. If you want to understand the structure of the line itself first, go back to the Invoice Lines in XMLpage, as it explains every field we will refer to here.

Last updated: 24 June 2026.

What error 1008 actually means

Every e-invoice in Saudi Arabia is built on the UBL 2.1 standard adopted by the Zakat, Tax and Customs Authority (ZATCA). Within this standard there is a strict principle: totals are not numbers you write freely, but a computed result that must be derived from the lines. The totals element is called cac:LegalMonetaryTotal, and inside it are several fields, each with a specific calculation rule.

The first of these fields is cbc:LineExtensionAmount inside the totals element. This field must equal the sum of the line amounts before tax. The reference rule in the EN 16931 standard carries the identifier BR-CO-10, and its text reads: the sum of Invoice line net amount must equal the sum of the line amounts for all invoice items. When your file violates this rule, Fatoora platform returns a rejection, and solution systems may surface it as a local code numbered 1008.

Note the important distinction: this error is not a structural error. The XML file may be perfectly valid from a schema (XSD) standpoint, with all fields present and of the correct types. The problem is purely logical: two numbers that should have matched did not. That is why editing the file’s structure will not help you; instead, review the calculation itself.

Error 1008 occurs specifically at the line net amount level (before tax). There are sibling errors that concern other fields inside the same element, such as the tax-inclusive total matching the tax-exclusive total plus tax (rule BR-CO-15). We covered that family in the Validation Errorsguide. Here we focus on a single gate: the sum of lines versus the total line amount.

Anatomy of the totals element and its relationship to the lines

To understand the error at its root, you must see the totals element as a computed chain, not as separate numbers. Each field is built on the one before it, and any break in a link of the chain carries over to what follows. The logical order of the fields is as follows:

• Line net amount (LineExtensionAmount): the sum of the line amounts before tax and before any document-level discount. This field is the gate of error 1008.
• Tax-exclusive amount (TaxExclusiveAmount): line net amount after adding charges and subtracting discounts at the document level.
• Tax-inclusive total (TaxInclusiveAmount): the tax-exclusive amount plus the total tax.
• Payable amount (PayableAmount): the tax-inclusive total after any prepaid amount or allowed final rounding.

The lesson here is that the line net amount is the first link. If it breaks, there is no point reviewing the following fields, because they build on a wrong number. That is why error 1008 must be fixed before looking at any other totals error. Many cases that seem complex and carry several rejection codes are all resolved simply by setting the first link correctly.

The governing rule that should be fixed in your mind: lines feed the totals in one direction only. You must never edit a totals field to match a number you expect; instead, you edit the lines if you want to change the result. Any attempt to “correct” the total manually without touching the lines is exactly what generates error 1008.

What the error message looks like

When Fatoora platform rejects the request, it returns a response carrying a list of errors. Each error carries a code, a message, and a type. This is a simplified example of a rejection response due to the sum of lines not matching the total:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "BR-CO-10",
        "category": "BR",
        "message": "Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)"
      }
    ],
    "warningMessages": [],
    "infoMessages": []
  },
  "reportingStatus": "NOT_REPORTED"
}

Read the message as an equation. The left side BT-106 is the sum of Invoice line net amount that you wrote in the totals element. The right side is the sum of all BT-131values, i.e. the amount of each line individually. The rule requires them to be exactly equal. Any difference, even a single halalah, is enough to reject the invoice.

The message does not tell you where the difference is or its size. It only tells you that the two sides are not equal. So your first task is not to guess, but to measure the difference precisely, as we will see in the detection section.

Causes of error 1008

Although the symptoms are the same (two totals that do not match), the root causes are practically limited to four families. Knowing which family your problem belongs to shortens the fix time to minutes.

Distribution of error 1008 causes

Cause one: non-unified rounding

This is the most common cause, and the most subtle. The rule in e-invoicing is that all monetary amounts are rounded to two decimal places. The problem arises from the order of rounding. If you round each line amount to two decimals and then sum the lines, you may get a different number than if you summed the full unrounded values and then rounded the result once.

A practical example: three items, each priced at 3.335 SAR. If you round each line first, each line becomes 3.34, and the sum is 10.02. But if you sum the full values 10.005 and then round, you get 10.01. The difference is a single halalah, but it is enough to reject the invoice. The adopted solution: round each line amount first, then sum the rounded amounts to form the total. That is, make the line the unit on which everything is built.

Cause two: a document-level discount or charge

Many people misunderstand where the discount goes. Error 1008 compares the sum of lines with the line net amount field (LineExtensionAmount) only, not with the payable amount. The document-level discount (cac:AllowanceCharge) is not subtracted from the line net amount; instead it enters a later field, the tax base (TaxExclusiveAmount).

The typical mistake: you subtract the discount from the sum of lines and write the result in the line net amount field. Then the total line amount will not match the sum of lines, and the file is rejected. The correct approach is that the line net amount equals the sum of lines as they are, before any document-level discount, and then the discount comes in the tax base step according to rule BR-CO-13: tax-exclusive amount = line net amount + document-level charges − document-level discounts.

Cause three: mixing tax-inclusive and tax-exclusive prices

In the e-invoice standard, the line amount (LineExtensionAmount) is the tax-exclusive value. When the merchant sells at prices the customer sees as tax-inclusive (common in direct-to-consumer selling), the system must separate the price into its two components before building the file.

If the system writes the inclusive price in the line amount field by mistake, the sum of lines will differ from the total computed on the correct basis, and error 1008 appears. The golden rule: convert every price to its tax-exclusive value at the line level first, then build all the totals from these clean values. Do not mix two different bases within the same file.

Cause four: editing a line manually without recalculating

This happens when someone edits an item’s quantity or price in an intermediate step (an export, a worksheet, a custom integration) after the total has been calculated. The line changes and the total stays old. The result is a small difference that is enough for rejection. This is a “human” cause more than a technical one, and its remedy is procedural: no line value may be edited after the totals are calculated except with a full recalculation.

How to pinpoint the difference precisely

Do not start by guessing. Start by measuring the difference numerically, because the number itself points you to the responsible family. Follow these steps in order.

Steps to diagnose error 1008

Step one: sum the lines manually. Extract the value of cbc:LineExtensionAmount from every cac:InvoiceLine element in the file, and sum them manually or with a simple tool. Keep the sum.

Step two: read the declared total. Read the value of cbc:LineExtensionAmount located inside the cac:LegalMonetaryTotalelement. This is the number the system objects to.

Step three: compute the difference and classify it. Subtract the manual sum from the declared total. The size of the difference is your clue:

• A difference of 0.01 or 0.02 SAR is usually a rounding problem (cause one).
• A difference equal to exactly a discount or charge you know means the discount entered the wrong field (cause two).
• A difference approaching the 15% tax rate of the invoice value means confusion between tax-inclusive and tax-exclusive prices (cause three).
• A random, irregular difference most likely means a late manual edit to one of the lines (cause four).

With this classification, you have turned a vague error message into a specific diagnosis. The fix afterward is straightforward.

Real-world scenarios where the error appears

Numbers alone may not clarify how the error sneaks into daily work. These are three situations business owners often encounter, all of which end in error 1008 if the calculation is not controlled.

Scenario one: a retail store selling at tax-inclusive prices. The merchant puts a final price for the customer on the shelf, say 23 SAR for the item. When issuing the invoice, the system must separate this price into 20 SAR tax-exclusive value and 3 SAR tax. If the system writes 23 in the line amount instead of 20, the sum of lines differs from the line net amount computed on the correct basis, and the error appears. The solution is for the separation mechanism to be fixed and unified before building any line.

Scenario two: a promotional offer with a discount on the invoice total. A services business grants the customer a 10% discount on the entire invoice. The employee subtracts the discount from the sum of lines and writes the result in the line net amount field. Here the match breaks immediately, because the line net amount must remain equal to the sum of lines before the discount. The correct place for the discount is the tax base step, not the line net amount.

Scenario three: a custom integration between two systems. A business exports sales data from a point-of-sale system to a tool that builds the XML file. During the transfer, one system rounds the lines while the other sums the full values. Scattered halalah differences arise in every invoice. This is the hardest situation to detect because the difference is small and variable. The solution is to unify the rounding policy in the system that builds the final file, rather than relying on a number coming from another system with a different policy.

The common thread across the three situations is clear: the problem arises whenever the source of the total is separated from the lines. As soon as you bind the totals to the lines with a single arithmetic bond, the error disappears at its roots.

How to fix error 1008

The radical fix rests on a single principle: make the lines the source of truth, and compute every total from them in the correct order. Do not write any total as a value computed in a separate place; instead derive it from the lines at the moment the file is built. Follow this sequence:

First, normalize the line values. Make sure each line amount is tax-exclusive and rounded to two decimal places. For each line: line amount = (quantity × unit price) minus any line-level discount, then round the result to two decimals.

Second, compute the line net amount by summing. Sum the rounded line amounts, and write the result in cac:LegalMonetaryTotal/cbc:LineExtensionAmount as is, without subtracting any document-level discount. Here error 1008 is resolved directly because the two sides will inevitably match.

Third, apply the discounts and charges in their correct field. Compute the tax base = line net amount + document-level charges − document-level discounts, and write it in cbc:TaxExclusiveAmount.

Fourth, derive the rest of the totals. Tax-inclusive total = tax base + total tax. The payable amount is computed after it. Each field is built on its predecessor in order, so there is no room left for contradiction.

This example shows the correct matching values for an invoice with three items after applying the sequence above:

<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="SAR">100.00</cbc:LineExtensionAmount> </cac:InvoiceLine>
<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="SAR">55.50</cbc:LineExtensionAmount>  </cac:InvoiceLine>
<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="SAR">44.50</cbc:LineExtensionAmount>  </cac:InvoiceLine>

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="SAR">200.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount  currencyID="SAR">200.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount  currencyID="SAR">230.00</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount       currencyID="SAR">230.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Note how the sum of lines (100.00 + 55.50 + 44.50) equals 200.00 exactly, which is itself the declared line net amount. This match is what is sought by rule BR-CO-10.

What if the error persists after the fix?

If you applied the correct sequence and error 1008 still appears, the cause is usually an edge case that deserves a closer inspection. Here are the most recurrent ones.

Multiple tax categories in a single invoice. When the invoice contains items at 15% and others that are exempt or at zero rate, the line net amount rule remains as is: the sum of all lines before tax regardless of their category. Make sure you sum all lines without excluding the exempt items, as dropping an exempt item from the sum is a common cause of an unexpected difference.

Lines with fractional quantities. Some sectors sell in fractional units such as the kilogram or the hour. Multiplying a fractional quantity by a unit price produces a value with more than two decimal places before rounding. Here rounding must be applied to the final line amount before summing it, not to the quantity or price separately, so that the sum aligns with the total.

Line-level discount versus document-level discount. The line discount is subtracted from the line amount itself before summing, so it enters within the line net amount. The invoice discount, however, is subtracted later in the tax base. Confusing the two positions generates the difference. Review every discount and ask: is it on a specific item or on the entire invoice? Place it in its correct position.

If you have ruled out these cases and the difference remains, it is most likely that an intermediate step in the file-building chain rewrites a number after it was calculated. Trace the value from line entry to XML generation, and you will find the step that breaks the match.

How Qoyod prevents error 1008

The difference between handling the error manually and leaving it to an accounting system is the difference between repeated fixing and permanent prevention. Qoyod is designed so that this problem never reaches you in the first place, through a clear working mechanism.

First, Qoyod builds every invoice directly from its lines. You enter the items with their quantities and prices, and the system computes each line amount, then derives the line net amount, the tax base, and the tax-inclusive total in the same order the standard requires. There is no number you write manually in a totals field to let it conflict with the lines.

Second, Qoyod unifies the rounding policy. All amounts are rounded to two decimal places at the line level first, then summed. This eliminates the family of rounding errors that result from summing full values and then rounding them later.

Third, Qoyod handles discounts and charges in their correct position. The document-level discount enters the tax base calculation, not the line net amount, exactly as the rule requires, so no conflict arises.

Fourth, Qoyod is officially certified for phase two of e-invoicing and connected to Fatoora platform. The system manages the Cryptographic Stamp Identifier for compliance (CSID) automatically, and generates the XML file and the QR code according to the specification, so your invoice reaches the Authority in a form that is correct in both structure and calculation.

Comparison: manual calculation versus Qoyod

The mental table is simple: the closer the source of the numbers is to the lines, the lower the probability of error. Manual calculation separates the total from its source, opening the door to contradiction. The accounting system binds them with an unbreakable bond.

A quick checklist before sending

Before you send any invoice, review these five points. Each one closes a door to error 1008:

• Each line amount is tax-exclusive and rounded to two decimal places.
• The line net amount in the totals element equals the sum of the line amounts exactly.
• The document-level discount or charge is in the tax base field, not in the line net amount.
• A single basis for prices across the whole file: all tax-exclusive at the line level.
• No line was edited after the totals were calculated without recalculating.

Frequently asked questions

What is the difference between error 1008 and the error concerning the tax-inclusive total?

Error 1008 concerns the line net amount layer before tax: the sum of the line amounts versus the line net amount field according to rule BR-CO-10. The tax-inclusive total error, however, concerns a higher layer: the tax-inclusive total matching the tax-exclusive amount plus the total tax according to rule BR-CO-15. The two layers may appear together, but fixing the line net amount first often resolves what follows.

My difference is only a single halalah, so can I ignore it?

It cannot be ignored. Fatoora platform requires an exact match, and a single-halalah difference is enough for rejection. The solution is not to ignore the difference but to remove its cause, which is usually the rounding order. Round at the line level first then sum, and do not sum full values then round the result.

Where do I put the overall invoice discount so it does not cause the error?

Put it in the document-level discount element (cac:AllowanceCharge at the document level), and let it affect only the tax base calculation. Do not subtract it from the line net amount, because the line net amount must remain equal to the sum of the lines as they are.

Could the cause of the error be value-added tax at the line level?

Error 1008 compares the tax-exclusive line amounts only, so tax does not directly enter this comparison. But if your system wrote the line amount as tax-inclusive by mistake, the problem will appear here. Make sure the line amount is always the tax-exclusive value.

Does the error occur with the simplified invoice (B2C) as with the tax invoice?

Yes. The rule that the sum of lines matches the line net amount applies to the tax invoice and the simplified tax invoice alike, because both are built on the same calculation model for the totals. The sending mechanism differs between the two types, but the totals logic is the same.

How do I avoid this error permanently without reviewing every invoice?

Use an accounting system that builds the totals from the lines automatically with unified rounding, such as Qoyod. Then the match becomes an inevitable result of the calculation method, not something you verify manually each time.

Related articles

• ZATCA e-invoicing errors
• Validation Errors
• Invoice Lines in XML
• Qoyod’s e-invoicing guide