Document Intelligence model prebuilt-check.us - Incorrect behaviour on WordAmount field/attribute

Question

Document Intelligence model prebuilt-check.us - Incorrect behaviour on WordAmount field/attribute

Sinha, Rahul 1 0

Hi,

We are using Azure Document Intelligence model (prebuilt-check.us) for extracting US check OCR

In below use case ..

Where content it's reading correctly for check as "Three Dollar's" however valueNumber it's giving as 510. Which is same as NumberAmount attribute..

Could you please advise how this valueNumber is deriving as 510 in this case? Is it just putting NumberAmount value as valueNumber ?

    "WordAmount": {

      "type": "number",

      **"valueNumber": 510.0,**

      **"content": "THREE DOLLAR'S ONLY\nDollars",**

      "boundingRegions": [

        {

          "pageNumber": 1,

          "polygon": [

            69.0,

            261.0,

            988.0,

            268.0,

            988.0,

            311.0,

            69.0,

            303.0

          ]

        }

      ],

      "spans": [

        {

          "offset": 159,

          "length": 27

        }

      ],

      "confidence": 0.378

    "**NumberAmount**": {

      "type": "number",

      "valueNumber": **510.0**,

      "content": "$**510**.00",

Sinha, Rahul 1 0 Reputation points

2026-04-07T19:13:49.9633333+00:00

Please advise.
Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-04-10T05:44:36.9466667+00:00

Hi Sinha, Rahul 1,

Thank you for reaching out on the Microsoft Q&A.

If you are facing issues while using the prebuilt bank check model, please note that prebuilt models in Azure Document Intelligence are dependent on the supported API version and regional availability.

The prebuilt bank check model is supported in the latest stable API versions, and you can use it to extract predefined fields from bank check documents without training a custom model.

However, if the model is not working as expected, please verify the following:

Make sure that your Document Intelligence resource is created in a supported region, as some prebuilt models may not be available in all regions.

Also confirm that you are using a supported API version while calling the service, since availability of prebuilt models can vary across API versions.

Azure Document Intelligence supports multiple models such as invoice, receipt, ID document, contract, and bank check that extract key fields from structured or semi structured documents and return the results in JSON format. [learn.microsoft.com]

You can refer to the official model overview documentation here for supported models and availability details: [learn.microsoft.com]

Hope this helps. Do let me know if you have any further queries.

Thankyou!
Sinha, Rahul 1 0 Reputation points

2026-04-14T15:54:54.6933333+00:00

Hi **Anshika Varshney,

** We are using prebuilt-check.us with available vesion as 2024-11-30.

our resource is created in Central US (Which is supported region as per Doument Studio).

We are using azure provided API to call model.

As per my first post , it's not clear why it would map NumberAmount valueNumber to WordAmount valueNumber when it's not able to convert wordAmount content to valueNumber?

This is failing most of our test cases where it's incorrectly mapping the value.

Any further insight will be useful here.
Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-04-15T10:50:47.3+00:00

Hi Sinha, Rahul 1,

Thanks for sharing the details, that helps a lot.

From a setup point of view, everything you described looks correct. You are using the prebuilt check us model with API version 2024 11 30, and Central US is a supported region for Document Intelligence. Using the Azure provided API is also the expected and supported way to call this model.

About the mapping issue you mentioned, this is more related to how the prebuilt check model works internally. The model tries to logically link the numeric amount and the written amount when it thinks they belong to the same value on the check. Even if the word amount cannot be confidently converted into a number, the model may still associate it with the NumberAmount field. Because of this, valueNumber can sometimes be populated incorrectly.

At the moment, the prebuilt model does not give a way to change or control this mapping behavior. It focuses more on grouping related fields rather than validating whether the word amount can always be accurately converted to a numeric value. This is why the same issue shows up across many test cases.

One practical workaround is to use the confidence scores returned in the response. In many incorrect mappings, the confidence for WordAmount or valueNumber is lower. You can also treat the word amount and numeric amount separately in post processing, instead of assuming they always match.

If your use case needs very strict accuracy between word and numeric amounts, a custom model trained on your specific check formats usually gives more predictable results than the prebuilt model.

I agree this behavior is confusing, and sharing a few concrete examples in the thread helps others using the same model understand this limitation better.

Thankyou!
Sinha, Rahul 1 0 Reputation points

2026-04-17T13:16:49.1+00:00

Hi **Anshika Varshney,

Thank you for insight.

We will check how we can handle this scenarios with confidence level.

As confidence level is very low for handwritten.

Thanks
Sinha, Rahul 1 0 Reputation points

2026-04-19T01:18:21.06+00:00
Hi Anshika Varshney,

Here is another unique scenario where confidence level will not wok for wordAmount.

as confidence is showing based on what OCR is reading.

In this case further logic need to implement along with confidence.

"WordAmount": { "type": "number", "valueNumber": 501.0, **"content": "DOLLARS",** "**confidence": 0.827** } "NumberAmount": { "type": "number", "valueNumber": 501.0, "content": "$ 501.00", "confidence": 0.804 },

2 answers

Your answer

Sinha, Rahul 1 0 Reputation points

2026-04-07T19:13:49.9633333+00:00

Please advise.
Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-04-10T05:44:36.9466667+00:00

Hi Sinha, Rahul 1,

Thank you for reaching out on the Microsoft Q&A.

If you are facing issues while using the prebuilt bank check model, please note that prebuilt models in Azure Document Intelligence are dependent on the supported API version and regional availability.

The prebuilt bank check model is supported in the latest stable API versions, and you can use it to extract predefined fields from bank check documents without training a custom model.

However, if the model is not working as expected, please verify the following:

Make sure that your Document Intelligence resource is created in a supported region, as some prebuilt models may not be available in all regions.

Also confirm that you are using a supported API version while calling the service, since availability of prebuilt models can vary across API versions.

Azure Document Intelligence supports multiple models such as invoice, receipt, ID document, contract, and bank check that extract key fields from structured or semi structured documents and return the results in JSON format. [learn.microsoft.com]

You can refer to the official model overview documentation here for supported models and availability details: [learn.microsoft.com]

Hope this helps. Do let me know if you have any further queries.

Thankyou!
Sinha, Rahul 1 0 Reputation points

2026-04-14T15:54:54.6933333+00:00

Hi **Anshika Varshney,

** We are using prebuilt-check.us with available vesion as 2024-11-30.

our resource is created in Central US (Which is supported region as per Doument Studio).

We are using azure provided API to call model.

As per my first post , it's not clear why it would map NumberAmount valueNumber to WordAmount valueNumber when it's not able to convert wordAmount content to valueNumber?

This is failing most of our test cases where it's incorrectly mapping the value.

Any further insight will be useful here.
Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-04-15T10:50:47.3+00:00

Hi Sinha, Rahul 1,

Thanks for sharing the details, that helps a lot.

From a setup point of view, everything you described looks correct. You are using the prebuilt check us model with API version 2024 11 30, and Central US is a supported region for Document Intelligence. Using the Azure provided API is also the expected and supported way to call this model.

About the mapping issue you mentioned, this is more related to how the prebuilt check model works internally. The model tries to logically link the numeric amount and the written amount when it thinks they belong to the same value on the check. Even if the word amount cannot be confidently converted into a number, the model may still associate it with the NumberAmount field. Because of this, valueNumber can sometimes be populated incorrectly.

At the moment, the prebuilt model does not give a way to change or control this mapping behavior. It focuses more on grouping related fields rather than validating whether the word amount can always be accurately converted to a numeric value. This is why the same issue shows up across many test cases.

One practical workaround is to use the confidence scores returned in the response. In many incorrect mappings, the confidence for WordAmount or valueNumber is lower. You can also treat the word amount and numeric amount separately in post processing, instead of assuming they always match.

If your use case needs very strict accuracy between word and numeric amounts, a custom model trained on your specific check formats usually gives more predictable results than the prebuilt model.

I agree this behavior is confusing, and sharing a few concrete examples in the thread helps others using the same model understand this limitation better.

Thankyou!
Sinha, Rahul 1 0 Reputation points

2026-04-17T13:16:49.1+00:00

Hi **Anshika Varshney,

Thank you for insight.

We will check how we can handle this scenarios with confidence level.

As confidence level is very low for handwritten.

Thanks
Sinha, Rahul 1 0 Reputation points

2026-04-19T01:18:21.06+00:00

Hi Anshika Varshney,

Here is another unique scenario where confidence level will not wok for wordAmount.

as confidence is showing based on what OCR is reading.

In this case further logic need to implement along with confidence.

"WordAmount": { "type": "number", "valueNumber": 501.0, **"content": "DOLLARS",** "**confidence": 0.827** } "NumberAmount": { "type": "number", "valueNumber": 501.0, "content": "$ 501.00", "confidence": 0.804 },

Answer 1

Samtayar Leehar 0

Interesting issue. It looks like the model is trying to infer the numeric value from surrounding fields instead of relying only on the written text, which can definitely cause problems in financial workflows. Using confidence scores and separate validation logic sounds like the safest workaround for now. For any system where calculations must be precise, I usually recommend an independent verification step with a simple GWA calculator or similar tool logic to cross-check outputs before final processing.

0 comments

Answer 2

Hello Rahul,

It is actually expected behavior for the Document Intelligence prebuilt-check.us model to normalize numeric extractions.

While the content attribute correctly captures the verbatim text string (e.g., "THREE DOLLAR'S ONLY"), the valueNumber field is designed to parse and return the numerical equivalent (e.g., 510.0) based on the overall context, often cross-referencing the NumberAmount field if the model's heuristics determine they represent the same financial entity. For precise text extraction without numerical conversion, you should adjust your application logic to exclusively pull from the content string or the spans array, rather than relying on the valueNumber attribute.

Share via

Document Intelligence model prebuilt-check.us - Incorrect behaviour on WordAmount field/attribute

2 answers

Your answer