Bedrock Data Automation Blueprint Schema

Last updated August 2026. Field limits and file requirements below were read from the Amazon Bedrock User Guide on 2026-08-18. Rates were read from the Bedrock pricing page the same day.

Short answer: a Bedrock Data Automation blueprint is a JSON schema you author that tells BDA which fields to pull out of a class of document, what type each field is, and how to normalize it. Two numbers decide the whole design. The synchronous InvokeDataAutomation API caps a blueprint at 15 fields; the asynchronous InvokeDataAutomationAsync API caps it at 100. Pricing changes at field 31, where every additional field adds $0.0005 per page on top of the $0.040 base rate. Design against those three boundaries and everything else falls into place.

What a blueprint actually is

AWS describes a blueprint as an artifact that configures your file processing business logic. In practice it is a list of field names, a data format for each one (string, number, boolean and so on), and a natural language instruction per field that tells the model how to normalize and validate what it finds. You create one blueprint per class of file: a W2, a pay stub, an ID card, a vendor invoice.

Each blueprint you create is a real AWS resource with its own blueprint ID and ARN, which means it is versionable, shareable across your account, and something your infrastructure team will expect to see in code rather than clicked into a console. There are catalog blueprints, which are premade starting points for common document classes, and custom blueprints for anything not in the catalog.

You can build one three ways: generate it from a blueprint prompt, add fields manually one at a time, or write the JSON directly in the JSON editor. The JSON editor is the one to use if you want the schema in version control, and a blueprint has a hard ceiling of 100,000 characters when JSON formatted.

Explicit fields and implicit fields

BDA splits extraction into two field types, and the distinction matters more than it sounds.

Explicit fields are for information stated plainly on the page. An invoice number printed next to the words "Invoice #" is explicit. So is a total, a due date, a vendor name in the letterhead.

Implicit fields are for information that has to be transformed or inferred from what is on the page. "Is this invoice past due as of the processing date" is implicit. So is "what currency is this in" when the document only shows a symbol, or "what is the net amount before tax" when the document prints only a gross figure and a tax rate.

Implicit fields are where blueprints earn their keep against a prebuilt model, and they are also where field counts quietly double. Every derived value you want in the output is another field against your cap and, past field 30, another line on your bill.

The two field ceilings nobody mentions

This is the constraint that should drive your architecture decision, and it is easy to miss because it sits in a note in the user guide rather than in the pricing discussion.

Fifteen fields is not many for an invoice. Vendor name, vendor address, tax ID, invoice number, invoice date, due date, PO number, currency, subtotal, tax, shipping, total, remit-to, payment terms and a bank reference is exactly fifteen, with nothing left for anything you actually want to derive. If your plan is the sync API, accept now that you are building a header-only extractor and that line items are a separate problem.

The async API at 100 fields is the realistic path for invoice work. It also means output lands in S3 rather than coming back inline, so you need a job-completion path, a place to put results, and something that reacts when a job fails quietly. Async pipelines that stop producing output without erroring are the classic failure mode here, and a simple health check on the downstream consumer catches it faster than a nightly reconciliation does.

Where the pricing cliff sits

The field cap and the pricing threshold are different numbers, which is the part that trips people up. BDA Custom Output on documents costs $0.040 per page for any blueprint with 30 fields or fewer. Each field above 30 adds $0.0005 per page. Across 1,000 pages that is $0.50 per extra field.

AWS confirms the mechanic in its own worked example: a 40-page document on a 20-field blueprint bills at $0.040 a page, while a 10-page document on a 40-field blueprint bills at $0.045. The rate is per blueprint, not per account, so two blueprints in the same batch can carry two different page rates. The full breakdown of how those rates stack up sits on our Bedrock Data Automation pricing page.

Read the table again and notice what it is telling you. Going from 30 fields to 100 fields raises your cost by 87.5 percent. If you are processing 100,000 pages a year, a sloppy schema costs $3,500 a year in nothing but field count.

An invoice blueprint that stays under 30 fields

Here is a schema that covers what an AP team actually posts, without crossing the threshold. Count as you go.

Vendor block (6): vendor name, vendor address, vendor tax ID, vendor email, remit-to name, remit-to address.

Document block (7): invoice number, invoice date, due date, PO number, currency, payment terms, invoice type (invoice or credit memo).

Money block (6): subtotal, tax amount, tax rate, shipping, discount, total.

Line items (5 attributes): description, quantity, unit price, line amount, item code.

Derived, implicit (4): is past due, net amount, line total check (does the sum of lines match the subtotal), and detected language.

That is 28 fields with two to spare. The line-item block is the one to watch: define it as a repeating structure with five attributes rather than as twenty separate fields for four expected rows, because a schema that hardcodes row positions will break on the first invoice with five rows and will burn your field budget doing it.

The derived block is where most teams overshoot. Every convenience field you add at extraction time is a field you pay for on every page forever. Computing "is past due" in your own code after extraction costs nothing. Ask of every implicit field whether the model needs to see the document to produce it. If the answer is no, it belongs in your application, not your blueprint.

The limits that will actually stop you

Field count is the constraint people plan for. These are the ones that surprise them, all from the BDA prerequisites documentation.

• 20 pages per document on the async API, rising to 3,000 only when the splitter is enabled. If you send bundled statement PDFs, turn the splitter on before you build anything else.
• 200 MB per file from the console, 500 MB via the API. Formats are PDF, TIFF, JPEG, PNG and DOCX. DOCX files get converted to PDF first, which breaks page number mapping.
• Six input languages: English, German, Spanish, French, Italian and Portuguese. If you take vendor invoices from Asia, check this before anything else.
• No vertical text. BDA reads horizontally arrayed text at any rotation, including 45 degrees, but not text written vertically as in Japanese or Chinese.
• Minimum 8 point text at 150 DPI (15 pixels of character height). Faxed and re-scanned invoices routinely land below that, and there is no warning when they do.
• No password protected PDFs. Strip protection upstream or the job fails.

One security note worth repeating because AWS flags it directly: blueprint fields and blueprint creation can involve prompts, and Amazon states plainly that it does not validate the intent of a blueprint. Only trusted sources should control that prompt input. If vendors or an inbox can influence what goes into a field instruction, treat that as an injection surface.

Five rules for designing the schema

1. Start from the posting record, not the document. List the fields your ERP actually requires to post a bill, then work backwards. Most first-draft blueprints capture eight fields nobody downstream consumes.
2. Keep derived values out. If your application can compute it from other extracted fields, compute it there. Implicit fields are for things that require reading the page.
3. Model line items as a repeating structure. Five attributes on a repeating group, not twenty flat fields. This is the single biggest field-count saving available.
4. Write the normalization instruction, do not skip it. The natural language context per field is where you say "return dates as YYYY-MM-DD" and "strip currency symbols". Skipping it moves the cleanup into your code and into your exception queue.
5. Keep the JSON in version control. Blueprints are AWS resources with IDs and ARNs. Author them in the JSON editor, commit the file, and treat a schema change like any other deploy.

When a blueprint is the wrong tool

Blueprints are worth the effort when you need fields a prebuilt model will never look for, and when you have engineers to author, test and version the schema against real vendor invoices. That is genuine value and it is what the 4x premium over Textract Analyze Expense buys.

They are the wrong tool when invoices are the whole job. Analyze Expense costs $0.010 per page and returns invoice fields plus line items with no schema to design at all, which is why our Textract versus Bedrock Data Automation comparison ends up favoring Textract for pure AP work. And if the people doing the work sit in accounting rather than engineering, neither service has an interface for them. Every change to what you capture becomes a code change, a blueprint version and a deploy. The integration itself is code somebody has to review and keep alive as vendors redesign their layouts, and even with an AI coding assistant drafting the first pass, that maintenance line does not go away.

If what you want is a folder of PDF invoices in and a spreadsheet out, with every line item captured, upload one at the top of this page and compare the result against what your blueprint returns. That test takes fifteen seconds and it answers the build-versus-buy question better than a cost model does.

Frequently asked questions

How many fields can a Bedrock Data Automation blueprint have?

It depends on the API. Blueprints used with InvokeDataAutomationAsync support a maximum of 100 fields. Blueprints used with the synchronous InvokeDataAutomation API support a maximum of 15. A blueprint is also capped at 100,000 characters when JSON formatted, which in practice binds later than the field count does.

What is the difference between explicit and implicit fields?

Explicit fields extract information stated plainly on the document, such as an invoice number or a total. Implicit fields extract information that has to be transformed or inferred, such as whether an invoice is past due or what the net amount is when only a gross figure is printed. Both count toward your field limit and your per page price.

Do more blueprint fields cost more?

Yes, past 30. BDA Custom Output on documents costs $0.040 per page for any blueprint with 30 fields or fewer, and each additional field adds $0.0005 per page. A 100-field blueprint costs $0.075 per page, which is 87.5 percent more than a 30-field one for the same document.

How do you create a Bedrock Data Automation blueprint?

Through the console or the API, using one of three methods: generate it from a blueprint prompt, add fields manually, or write the schema in the JSON editor. Each blueprint becomes an AWS resource with its own ID and ARN. Catalog blueprints give you a premade starting point for common document classes.

Can a blueprint handle multi-page invoices?

Up to 20 pages per document on the async API by default. Enabling the splitter raises that to 3,000 pages per document. File size caps at 200 MB from the console and 500 MB via the API, across PDF, TIFF, JPEG, PNG and DOCX.