# POST /jobmaterial.json validator rejecting submissions with displayed\_amount\_is\_tax\_inclusive "0" as if they were "1"

**URL:** <https://community.servicem8.com/t/post-jobmaterial-json-validator-rejecting-submissions-with-displayed-amount-is-tax-inclusive-0-as-if-they-were-1/1119>\
**Category:** API & SDK\
**Created:** [May 29, 2026, 4:44am UTC](https://community.servicem8.com/t/post-jobmaterial-json-validator-rejecting-submissions-with-displayed-amount-is-tax-inclusive-0-as-if-they-were-1/1119 "2026-05-29T04:44:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![frederico\_carvalho](https://avatars.discourse-cdn.com/v4/letter/f/e19adc/32.png) [@frederico\_carvalho](https://community.servicem8.com/u/frederico_carvalho)\
**Post date:** [May 29, 2026, 4:44am UTC](https://community.servicem8.com/t/post-jobmaterial-json-validator-rejecting-submissions-with-displayed-amount-is-tax-inclusive-0-as-if-they-were-1/1119/1 "2026-05-29T04:44:34Z")

</div>

I tried to go through support for this but I’ve been told (possibly by an LLM) that this is the only way to report bugs - my original report there contains specifics around which customers are affected - if you are able to find that ticket you’ll have more details.

I work for Groundplan, which integrates with ServiceM8 via the API. Since May 22, for some customers, we’ve been observing POST /jobmaterial.json returning 400 “inc-tax and ex-tax prices are inconsistent.” on submissions that declare their values as tax-exclusive. The validator’s arithmetic implies it is ignoring the displayed\_amount\_is\_tax\_inclusive flag we send.

In every observed failure, the returned X exactly equals submitted\_price / (1 + 0.10) — the validator strips a 10% tax from our submitted value as if it were tax-inclusive, despite our flag saying it is not.

A failing request body (shape, with generic values):

{  
“active”: 1,  
“cost”: “62.00”,  
“displayed\_amount”: “80.60”,  
“displayed\_amount\_is\_tax\_inclusive”: “0”,  
“displayed\_cost”: “62.00”,  
“job\_uuid”: “”,  
“name”: “”,  
“price”: “80.60”,  
“quantity”: “1.00”,  
“sort\_order”: “100”,  
“uuid”: “”  
}

Response:

{  
“errorCode”: 400,  
“message”: “inc-tax and ex-tax prices are inconsistent. Expected price [73.27].”  
}

80.60 / 1.10 = 73.27 exactly. price equals displayed\_amount, both declared as tax-exclusive via the flag. My understanding of displayed\_amount\_is\_tax\_inclusive field is that if I set it to 0, the displayed\_amount is tax exclusive, therefore it should match the price.

When testing against our own ServiceM8 account with an identical request shape (price == displayed\_amount, displayed\_amount\_is\_tax\_inclusive “0”, body uuid set, no material\_uuid), POST /jobmaterial.json accepts the submission in every configuration we’ve been able to construct:

- against a fresh row;
- against an existing row whose stored displayed\_amount\_is\_tax\_inclusive is “1” from a prior API call;
- against an existing row whose stored displayed\_amount\_is\_tax\_inclusive is “1” from creation via the ServiceM8 web UI;
- regardless of whether the catalogue material referenced has price\_includes\_taxes 0 or 1.

In each case the row is updated, the stored displayed\_amount\_is\_tax\_inclusive flips to “0”, and stored price/displayed\_amount update to the submitted values. The validator does not fire.

The failures are limited to specific ServiceM8 accounts. We cannot reproduce the rejection in our own account using the same body shape, so it appears to only affect certain accounts, or possibly certain materials. There seems to be a correlation between customers who have reported this problem and the use of integrations to drive materials/bundles, in particular Burdi and Xero.

I’d really appreciate some attention on this issue as it’s currently affecting customers of both our companies and holding them up from performing quotes. I suspect it might be a change to how data comes in from integrations, or possible we’ve just been doing it wrong the whole time and it only just started validating it? Either way would love to know.

Thanks

(Alex Gilleran, posting under Frederico’s account)

---

<div class="post-metadata">

**Author:** ![Cody](https://sea2.discourse-cdn.com/flex002/user_avatar/community.servicem8.com/cody/32/52_2.png) [@Cody](https://community.servicem8.com/u/Cody)\
**Post date:** [May 29, 2026, 6:14am UTC](https://community.servicem8.com/t/post-jobmaterial-json-validator-rejecting-submissions-with-displayed-amount-is-tax-inclusive-0-as-if-they-were-1/1119/2 "2026-05-29T06:14:38Z")

</div>

Thanks for the detailed report.

We reproduced the issue and confirmed it was an API validation issue affecting some Job Material requests where `displayed_amount_is_tax_inclusive` was supplied as `0` or `false`.

The related change has now been rolled back, and this should no longer be occurring.

Sorry for the disruption, and thanks again for raising it.

---

<div class="post-metadata">

**Author:** ![frederico\_carvalho](https://avatars.discourse-cdn.com/v4/letter/f/e19adc/32.png) [@frederico\_carvalho](https://community.servicem8.com/u/frederico_carvalho)\
**Post date:** [May 29, 2026, 6:27am UTC](https://community.servicem8.com/t/post-jobmaterial-json-validator-rejecting-submissions-with-displayed-amount-is-tax-inclusive-0-as-if-they-were-1/1119/3 "2026-05-29T06:27:01Z")

</div>

Awesome, thanks Cody! We’ll keep an eye on it from our end