hyphenated first name truncated in Document Intelligence

Hello @Thomas Markut

Thank you for reporting this behavior.

Based on your example, where hyphenated French first names such as "Jean-Philippe" or "Marie-Christine" are returned as only "Jean" or "Marie" in the FirstName field, I could not find documentation that identifies this as a known limitation or configurable pattern for the prebuilt identity document model.

A few recommendations that may help narrow down the behavior:

• Test with multiple identity documents containing hyphenated names to determine whether the truncation is consistent across different document layouts and scan qualities.
• Review the Document Intelligence known issues documentation to see whether any related OCR or field extraction limitations apply to your scenario.
• Verify whether the behavior occurs only with specific hyphen formats (for example, standard hyphen, spaced hyphen, or other punctuation characters).
• If this behavior consistently affects your business scenario, consider evaluating a custom extraction model, which may provide better accuracy for document formats and naming conventions specific to your workload.

For reference:

• Document Intelligence known issues
• https://learn.microsoft.com/azure/ai-services/document-intelligence/overview?view=doc-intel-4.0.0

Could you also share:

• The model being used (for example, prebuilt-idDocument)
• Whether the names are printed or handwritten
• A redacted sample of the extracted JSON response showing the FirstName field

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

Thankyou!

Thank you for your feedback.

I'm using prebuilt-idDocument.

I also noticed that from time to time, some hyphenated French first names are well detected with the previous version (V3.1), whereas the V4 is systematically, returning only the first part of the name.
Names are printed on the document / image.

V4 response

"FirstName": {
						"type": "string",
						"valueString": "Maëlys",
						"content": "Maëlys",
						"boundingRegions": [
							{
								"pageNumber": 1,
								"polygon": [
									1838,
									1080,
									2261,
									1081,
									2260,
									1199,
									1837,
									1199
								]
							}
						],
						"confidence": 0.943,
						"spans": [
							{
								"offset": 129,
								"length": 6
							}
						]
					}

V3.1 response

"FirstName": {
						"type": "string",
						"valueString": "Maëlys -Gaëlle, Marie",
						"content": "Maëlys -Gaëlle, Marie",
						"boundingRegions": [
							{
								"pageNumber": 1,
								"polygon": [
									1832,
									1079,
									3226,
									1072,
									3227,
									1200,
									1833,
									1206
								]
							}
						],
						"confidence": 0.381,
						"spans": [
							{
								"offset": 234,
								"length": 21
							}
						]
					}

Hello @Thomas Markut ,Thank you for sharing the comparison between V3.1 and V4.

From the examples provided, I can see that the V4 prebuilt-idDocument model is consistently returning only the first portion of the hyphenated given name ("Maëlys"), whereas V3.1 extracted the complete value ("Maëlys-Gaëlle, Marie"). The bounding region in V4 also appears to cover only the first name segment, which suggests this may be related to how the V4 model is interpreting and normalizing the FirstName field rather than an OCR recognition issue.

Since the name is clearly printed on the document and you are observing consistent behavior across multiple French hyphenated first names, this could indicate a model behavior change between V3.1 and V4 for the prebuilt-idDocument model.

Could you please share:

A redacted sample document that reproduces the issue (if possible).

The document country/ID type.

The API version being used for V4.

Whether the full hyphenated name is present in the OCR/content output but truncated only in the extracted FirstName field.

This information will help determine whether the behavior is expected field normalization or a potential regression in the V4 model.

In the meantime, if preserving the complete hyphenated first name is a business requirement, you may consider using the OCR/content output as a temporary workaround and validating the extracted name against the document text until we can better understand the model behavior.

Thank you, and I look forward to your update.

Hello,

You can use the sample document from official French ANTS website : https://passeport.ants.gouv.fr/files/0d729964-aee5-46a8-90aa-34b2619074a2/9addba5e-ce68-4a1e-aba6-eb1d6d851e77/4610d586-5973-431b-a1c2-3eaa2cfd24f0.jpg

It's a French CNI ID document and i'm using Prebuilt-idDocument API version 2024-11-30 (V4.0 general availability) compared to API Version 2023-07-31 (V3.1 general availability)

Unfortunaltely, the content output with the V4 is truncated as well because, as you said, the bounding region in V4 also appears to cover only the first name segment ..

Thanks in advance