The dreaded Internal Error😱 on /Sale/Invoice/Item endpoint

JeremyF

Hi Dev Community

 

We have two Sales orders out of many hundreds that refuse to be processed.

 

Have checked all the causes we've had in the past but nothing seems to stand out

 

Has any one else come across this and solved the issue?

 

Cheers

 

Jeremy

 

JeremyF

Tana from API Support to the rescue on this one. 

 

The issue was with rounding for Total Calculation for an item.

 

Although the Line Total for an Item is marked as mandatory in the API documentation you should not pass a value here and let the MYOB API calculate it. 

 

If your application is not rounding it exactly to what the MYOB back end rounds it to you will get an Internal Error that is hard to debug. 

 

Thanks Tana and API support 

 

Here is the excellent explanation from Tana

Hi Jeremy,
Thanks for sending through the full payloads and logs. I can see why this one’s been tricky.
I’ve gone through both failing requests carefully, and while the API is returning a generic 500 InternalError, there are a few strong indicators this is actually being triggered by data-level validation issues inside AccountRight, rather than a platform outage.
 

What’s happening

You’re successfully:

• Authenticating
• Hitting the correct endpoint
• Sending structurally valid JSON 

But specific invoices are failing during backend processing, which is why you’re getting:

"An exception was thrown that was not handled correctly"

This typically means:
The request passes API validation, but AccountRight fails when trying to save the transaction internally
 

Likely causes (based on your payload)

There are a few red flags in both examples that commonly trigger this exact behaviour:
 

1. Decimal precision issues 

You’re sending values like:

"UnitPrice": 241.007
"UnitPrice": 721.438
"ShipQuantity": 2.452
"ShipQuantity": 0.304

AccountRight typically expects:

• UnitPrice > max 2–4 decimal places (depending on file config)
• Quantities > limited precision (often 2–3 decimals max)

Values like 241.007 or 721.438 can cause silent rounding failures internally.
 

2. Line Total mismatch (high probability)

You’re sending all three fields together:

ShipQuantity + UnitPrice + DiscountPercent + Total

MYOB recalculates totals internally. If your Total doesn’t exactly match their calculation (after rounding rules), it can throw an internal exception.
Example risk:

2.452 × 241.007 × 50% ≠ 295.47 (after MYOB rounding)

Even a 1-cent mismatch can break it.
 

3. Mix of high precision + discount

The combination of:

• fractional quantities
• high precision prices
• 50% discounts

This is a known trigger pattern for internal errors in AccountRight.
 

4. Freight + TaxCode edge case (less likely but worth checking)

You’re using:

"Freight": 133,
"FreightTaxCode": { "UID": "..." }

If:

• the tax code is inactive, or
• not valid for sales

…it can fail internally without a clean validation error.
 

What to test (quick isolation steps)

To pinpoint this quickly, I’d suggest:

Step 1 – Remove Total from lines

Let MYOB calculate it:

{
"ShipQuantity": 2.31,
"UnitPrice": 307.8,
"DiscountPercent": 50
}

 

Step 2 – Round values

Try:

• UnitPrice > 2 decimals
• Quantity > max 3 decimals

 

Step 3 – Test a failing invoice with:

• Only 1–2 lines
• No discount

If that works > reintroduce complexity step-by-step.
 

Step 4 – Try the same invoice via UI

If it also fails in AccountRight UI:
confirms this is data-specific, not API-related

Recommended fix approach

The most reliable pattern with AccountRight is:
✔️ Send:

• ShipQuantity
• UnitPrice
• DiscountPercent

❌ Do NOT send:

• Total

Let MYOB handle:

• rounding
• tax calculation
• totals

 Example corrected payload (line)

{
"ShipQuantity": 2.45,
"UnitPrice": 241.01,
"DiscountPercent": 50,
"Item": { "UID": "..." },
"TaxCode": { "UID": "..." }
}

 

One more thing

Since only 2 out of ~50 invoices fail, that strongly points to:
specific value combinations, not your integration setup
 
If you’re happy to share one of the failing invoices with Total removed and rounded values, I can sanity-check it before you retry.
Kind regards,

Tana

API Integration Analyst