AI-103 Practice Question 60: Layout Model Table Extraction
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 6 · question 10 of 10
An accounting team receives scanned supplier statements. Every supplier lays its statement out differently, but each one contains an itemized table of charges that must load into a spreadsheet reconciliation tool with its rows and columns intact, not as a wall of extracted text. There's no fixed set of fields shared across suppliers, so a model built around a specific schema won't generalize. A colleague suggests just running OCR and reading the results manually.
Which Document Intelligence approach preserves what the reconciliation tool needs?
Show answer and explanation
Answer:
The layout model is built for exactly this requirement: "Extracting tables is a key requirement for processing documents that contain large volumes of data typically formatted as tables." Extracted table information "includes the number of columns and rows, row span, and column span," and "each table cell contains the row and column index" (the structure a spreadsheet tool needs to reconstruct the grid), and it works with no fixed schema and no training per supplier.
- A is wrong because prebuilt-read returns OCR text, lines, and words without any table structure. The team would be left doing what the colleague suggested, reading raw text and manually figuring out which words belonged in which row and column. - B is wrong because prebuilt-invoice is built around a fixed invoice schema. Supplier statements aren't invoices, and forcing a fixed field set onto documents with no shared layout either misses data or requires a custom model per supplier, the constraint the stem rules out. - D is wrong because the general document model extracts key-value pairs, a single label paired with a single value, such as "Date: March 3." That structure doesn't represent a multi-row, multi-column itemized table.