Supplier Invoice Fields for Bookkeeping: What to Capture

Clean supplier-invoice bookkeeping does not need a longer flat list of fields. It needs the right fields, organized into the five decision categories the work actually breaks into: must-capture header, line-level detail, control and matching, tax and compliance, and audit-trace. Every decision a finance team makes about which supplier-invoice fields to capture — what to standardize across suppliers, what to capture at line resolution, what to feed the VAT return, what to retain for audit — sits inside one of those five categories.

The headline fields per category, in extractable form: header carries the invoice number, invoice date, supplier identity, header totals (net, tax, gross), and currency. Line-level carries the line description, quantity, unit price, line tax rate, and line total. Control and matching carries the PO number, payment terms, supplier bank details, and supplier ID. Tax and compliance carries the VAT-rate breakdowns, statutory tax IDs (VAT number, ABN, GSTIN, EIN, and the rest), and reverse-charge or exempt flags. Audit-trace carries the source-file reference, page number, ingestion timestamp, and extraction confidence.

The reframe matters because the cost of skipping each category lands in a specific downstream place. Skip header fields and the AP record cannot be posted at all. Skip line-level detail and three-way matching collapses, mixed-rate VAT returns mis-file, and cost allocation reverts to blanket coding. Skip control and matching fields and duplicate payments get through and bank-detail fraud goes uncaught. Skip tax and compliance fields and input VAT cannot be reclaimed and statutory audits flag missing IDs. Skip audit-trace fields and the team cannot reach the source document weeks later when an auditor or a supplier asks. Capturing too few of the right fields breaks one of these jobs; capturing extras without normalization just adds reconciliation work without supporting any decision. The right schema is the smallest set of fields the team's posting, matching, audit, and reporting logic actually depends on.

This split is not an in-house invention. The OASIS UBL 2.1 invoice schema — the international Universal Business Language standard — structures an invoice into header references to related orders, despatch advices, and receipts; invoice lines; compound tax information; and charges, the same field categories any in-house supplier-invoice schema has to account for. The same shape shows up across ERP screens, e-invoicing formats, and AP automation tooling regardless of vendor, because the underlying bookkeeping work is the same.

The rest of this article is a reference. Each category section names the fields that belong in it, the bookkeeping decision the category serves, the concrete failure that follows when capture is missing or inconsistent, and the normalization expectations that turn raw extraction into postable data. Scan to the category you are stuck on and act on it; reading top to bottom is optional. If what you actually want is a flat field-by-field walk-through with a sample invoice record rather than a schema-decision framework, the field-by-field invoice data entry walk-through is the companion piece for that.

---

Must-Capture Header Fields: The Minimum for an AP Record to Exist

Header fields are the foundation layer. Without them, no AP subledger record exists for the invoice — there is nothing to post to, nothing to match against, nothing to retain for audit. Every other category in this article assumes the header is captured. The minimum set is shorter than most field lists suggest, but each item is load-bearing.

The must-capture header fields are: invoice number, invoice date, supplier identity (legal name, plus tax ID and bank details where the invoice carries them), customer identity (which legal entity within the buyer organization the invoice is addressed to, when the buyer operates more than one), currency, header totals at three levels (net, tax, and gross), due date, and payment terms. Three-level totals matter even when only the gross is being paid: the net feeds the cost line, the tax feeds the VAT or GST control account, and the gross is what reconciles to the supplier statement.

The bookkeeping decision served is invoice posting itself. Get any of these fields wrong and the failure is immediate, not theoretical. A missing or wrong invoice date breaks tax-point determination and can push the invoice into the wrong VAT or GST period — which, depending on the jurisdiction, either delays an input-VAT reclaim by a quarter or forces a return correction. Inconsistent currency capture turns multi-currency bookkeeping into a manual reconciliation exercise, because the FX-translated GL amount no longer ties cleanly to the AP register entry. Three different printed spellings of the same supplier collapse into three subledger accounts when supplier identity is captured loosely, breaking supplier statement reconciliation and producing duplicate-supplier balances that take days to unwind. And when header totals at the net or tax level are missing, the bookkeeper has to derive them from line items, which fails quietly whenever line totals don't reconcile cleanly to header — and they often don't, because of supplier-side rounding.

Normalization is where most header schemas silently fail, so it deserves the same weight as the field list itself. Date format collisions are the single most common silent failure: the same string 02/03/2024 is March 2nd in the US, February 3rd in the UK, and ambiguous to an extraction tool that does not know the supplier's locale. The schema decision is to store dates as ISO YYYY-MM-DD and to do the locale interpretation at capture, not to defer it to whichever downstream system parses the field next. Invoice-number cleanup matters because duplicate-payment detection is almost always keyed on the invoice number, and inconsistent treatment of leading zeros, separator characters, or supplier-side prefix conventions defeats the duplicate check — INV-0042 and INV42 posted as different invoices is the canonical way a duplicate slips through. Supplier-name variants are best handled by treating the tax ID (or the buyer-side supplier code, where one exists) as the canonical key rather than the printed name, because suppliers print their own names inconsistently across templates. Currency codes should arrive as ISO 4217 three-letter codes — USD, EUR, GBP — regardless of how the supplier prints the symbol; the symbol is for humans, the code is for the schema.

Header capture is also not where the AP workflow starts. Invoices have to arrive in the team's hands before any field decision is made, which is its own problem with its own failure modes — see the digital mailroom for AP invoice intake piece for that side.

---

Line-Level Fields: When Header Capture Isn't Enough

Line-level capture is the most expensive category to get wrong because the failure modes show up later than header failures and unwinding them at month-end is manual work. The header-vs-line-item invoice fields decision is therefore not a matter of taste — it follows directly from how the invoice will be posted, matched, and reported.

The line-level fields are: line description, quantity, unit price, line total, line tax rate, line tax amount, optional product or SKU code, and optional account or cost-center hint. The two optional fields earn their place only when the team's coding logic uses them; capturing them as a default — because they happen to be present — adds reconciliation work without a downstream decision to support.

The decision rule for whether line capture is required is concrete. Header-only capture works when the invoice will be posted as a single GL line, at a single account, with a single tax treatment — uniform-category invoices with no PO and no allocation requirement. A supplier billing a single recurring service to a single cost center is the canonical case. Line-level capture is non-negotiable when any of four conditions hold: the invoice is multi-category and different lines need to code to different GL accounts; the invoice is matched against a PO at line resolution rather than header total; the lines carry different tax rates (standard, reduced, zero-rated, or exempt mixed on one document); or project, job, or cost-center allocation requires per-line attribution.

The bookkeeping decisions line capture serves follow the same conditions. Cost allocation across GL accounts and cost centers needs each line attributed individually. Three-way matching that runs at line resolution — invoice line to PO line to receipted quantity — collapses without it. Mixed-rate VAT or GST treatment requires the rate to be captured per line; the header tax breakdown alone is not enough to substantiate the return. Project and job costing depends on per-line attribution because WIP and margin reporting roll up from line-level cost transactions, not from invoice-level ones.

The downstream failure modes when line capture is missed in cases that require it are concrete and recurring. Header-only capture forces blanket coding to a single account, losing the category granularity the GL is supposed to give the management accounts — and the only way to recover the category split is to re-examine each invoice manually before posting, which is the work line capture was supposed to eliminate. Three-way matching collapses outright when the invoice's individual lines don't tie to PO lines, because the matching logic is line-resolution, not header-resolution. Mixed-rate VAT returns mis-file because the rate breakdown the return requires is gone — the header tax of, say, 12% on a mixed 20% and 5% invoice tells the return engine nothing useful. Cost-center reporting reverts to allocations made by guesswork at month-end, which is exactly the failure mode line capture exists to prevent.

Line-level normalization has its own characteristic problems. Unit-of-measure variants across suppliers are pervasive: each, EA, pcs, units, kg, m, and hrs all mean different physical things, and the same physical thing is named differently across suppliers. The schema has to decide whether to canonicalize at extraction or leave the supplier's value untouched and canonicalize downstream — both are valid, but doing it twice or doing it nowhere both produce errors. Rounding reconciliation between the sum of line tax and the header tax is the source of small but persistent variances; suppliers compute tax per line in different orders and at different rounding precisions, so the schema needs a rule for whether the captured line-tax sum or the captured header tax is authoritative when they disagree by a cent or two. Sub-totals before discount versus after discount matter when the invoice carries a header-level or line-level discount, because reproducing the supplier's arithmetic sometimes requires both — capturing only the after-discount line total loses information you may need later.

Line capture is also a technical problem of its own, because invoices present line data as tables whose structure varies widely across suppliers. The schema discussion above assumes the lines arrive in clean rows; the work of getting them there is its own subject — see the piece on extracting invoice line items from table data for that side.

---

Control and Matching Fields: Stopping Wrong Payments Before They Happen

Control and matching fields exist because the AP function pays money out, and a supplier invoice schema for AP that takes payment integrity seriously has to capture the fields that prevent the wrong payments. These are not bookkeeping fields in the posting sense — they are control fields whose job is to ensure that what gets posted is correct in the first place.

The control and matching fields are: PO number, GRN or delivery-note reference, contract reference, supplier bank account number (captured for fraud control), payment terms (and net days), and early-payment discount terms. Bank details overlap with header capture but earn their own treatment here because the use is different: in the header context, bank details record where to pay; in the control context, they are the value compared against the supplier master to detect a fraudulent change.

The bookkeeping decisions these fields serve are the ones an audit committee asks about. Three-way matching ties invoice to PO to GRN, and four-way matching adds contract reference where the contract terms are the additional gating control. Duplicate-payment detection runs across the AP register using the invoice number as its primary key and the supplier ID, total, and date as confirming attributes. Supplier-fraud control on bank-detail changes catches the impostor email that asks AP to pay the next invoice into a new account. Cash-flow timing — payment scheduling against terms and the decision to take or skip an early-payment discount — depends on captured terms, not assumed defaults.

The failure modes when these fields are captured inconsistently are recurring and expensive. A PO match fails outright when the invoice's PO number is captured in a different format than the PO record — leading zeros stripped on one side and not the other, hyphens in the PO record but not on the printed invoice, or the reverse — and the matching engine treats PO-00042 and PO42 as different orders. A PO match silently goes to the wrong PO line when line-level PO references are captured at the header instead of the line, conflating two POs from the same supplier into one — the invoice posts cleanly, the matching engine reports green, but the line allocation is wrong and the GL eventually disagrees with the receipts ledger. A duplicate payment slips through when the same invoice arrives in two formats (a PDF and a re-issued PDF, or a PDF and an email body) and the duplicate-detection key is the un-normalized invoice number, so two records exist that look different to the system. A fraudulent change of supplier bank details on a single invoice goes uncaught when bank details are treated as free-text in the footer rather than as a structured field compared against the supplier master at capture.

Normalization for control fields is more aggressive than for header fields, because the cost of getting it wrong is direct payment risk. PO-number formats vary widely across suppliers, and the cleanup rule has to be explicit: strip leading zeros consistently, normalize separators, and decide whether to canonicalize the captured value against the buyer-side PO master at extraction time rather than at matching time. Contract reference and PO reference can be confused when both appear on an invoice; the schema has to decide which is the matching anchor and which is metadata, and the decision needs to be documented because a wrong choice produces silent matching errors. Supplier bank details should be captured as a structured field — sort code or routing number, account number, IBAN where applicable — not as part of a footer free-text blob, so they can be compared against the supplier master deterministically rather than by string similarity.

Capture is necessary but not sufficient for any of this. Control fields only do their job when the validation rules that consume them are explicitly defined — what counts as a valid PO match, what triggers a duplicate-payment exception, what routes a bank-detail change to a manual approval queue. The dedicated invoice validation process and checklist walks through that consumption side.

---

Tax and Compliance Fields: VAT Returns, Reverse Charges, and Statutory IDs

Tax and compliance is where the schema meets statutory machinery. The reason these are invoice fields to standardize for accounts payable rather than a generic tax checklist is that the consequences are both monetary and audit-visible: a missed input-VAT reclaim costs cash, a mishandled reverse charge costs cash and triggers a return correction, and a missing statutory ID costs nothing immediately but becomes an audit finding in a quarter or two.

The tax and compliance fields are: VAT or GST rate per line and per rate-group; the header-level tax breakdown by rate (so the invoice supports the return engine without re-deriving from lines every time); the supplier's statutory tax ID, which varies by jurisdiction (VAT number for the EU and UK, ABN for Australia, GSTIN for India, EIN or state-tax registration numbers for the US, and equivalents elsewhere); reverse-charge, zero-rate, and exempt flags where the supplier indicates them; place-of-supply for cross-border transactions where the VAT or GST treatment depends on it; and e-invoicing identifiers (Peppol participant IDs, structured-invoice format references) where the jurisdiction or counterparty operates under one.

The bookkeeping decisions these fields serve cluster around the periodic return and the longer-term audit. The VAT or GST return depends on rate breakdowns being captured per rate, not just an aggregate header tax. Input-tax reclaim depends on the supplier's tax ID being captured against each posted invoice — most jurisdictions disallow input VAT where the invoice record cannot show the supplier's VAT number was on the document. Reverse-charge accounting depends on the flag being captured: domestic reverse-charge regimes (CIS in the UK construction sector, certain commodities elsewhere) and cross-border services both require the receiving entity to self-account, and the trigger is the flag on the invoice. Withholding tax — where the buyer is required to withhold a percentage of the gross before paying the supplier — depends on the schema knowing which suppliers and which line types fall under it. Cross-border posting that depends on place-of-supply, and e-invoicing compliance where the jurisdiction mandates structured submission, both depend on the relevant identifiers being on the captured record.

The failure modes are concrete enough that the cost can be quantified. A VAT return error or refund delay follows when input VAT cannot be substantiated to specific invoices because the rate breakdown was not captured — the return engine sees a single header tax figure with no rate attribution, and either the return is filed with an unsupported reclaim or the reclaim is held back until the underlying invoices can be re-examined. Lost input-VAT reclaim follows when the supplier's VAT number is captured incorrectly or not at all on invoices the team intended to claim against; jurisdictions disallow the reclaim regardless of whether the underlying transaction was legitimate, and the lost cash is permanent. Reverse charge mishandled produces a return correction when the receiving entity reported standard input VAT on a transaction that should have been self-accounted; the correction is administrative but visible to the tax authority. An audit finding for a missing statutory ID lands even when the underlying tax treatment was correct, because the audit requires the ID to be retained against the posted record — the substance does not save the schema if the form is missing.

Normalization for tax fields has its own characteristic problems. Tax-rate format collisions are pervasive: rates captured as 20, 20%, 0.20, or 0.2 are the same value mathematically and behave very differently downstream — Excel applies percentage formatting to one and not the other, accounting systems multiply by the integer or the decimal depending on configuration, and a return engine that expects one form silently mis-files when given another. The schema decision is to pick one canonical representation and convert at capture, not to leave it to whichever consuming system parses the field. Jurisdictional variants of the same supplier's tax ID matter when an EU supplier prints both an EU VAT number (used for cross-border treatment) and a domestic tax registration number on the same invoice; the schema needs to decide which is the canonical anchor for which tax treatment, not capture both ambiguously. Multi-rate consolidation matters because the line-level tax rates have to be summable into the header-level rate-group breakdown that the return engine consumes, and rounding rules across the lines have to be consistent or the rate-group totals do not tie to the captured header.

E-invoicing changes the schema-ownership question in jurisdictions where it is mandated. Where the structured invoice format is determined externally (Peppol BIS, the various country-specific formats), the schema is no longer a buyer-side decision in the strict sense — the supplier sends a structured payload, and the buyer-side schema's job is to capture the identifiers (Peppol participant IDs, format codes, document references) that link the buyer's record back to what was submitted. As more jurisdictions move to mandatory e-invoicing, more fields move into this category.

---

Audit-Trace Fields: Connecting Every Posted Record Back to a Document

Most field lists stop at the four categories above, because those categories are what comes off the invoice itself. Audit-trace fields are different: they are produced by the workflow that ingested the invoice, not by the supplier. The schema-as-decision question for this category is whether to treat invoice audit trail fields as a process problem (file the PDFs somewhere and trust people will find them) or as a schema problem (attach the trace fields to every record at posting time). The first approach works at small volumes and breaks at the scale where AP automation is needed.

The audit-trace fields are: the source-file reference (a stable internal identifier for the original PDF or image, not the original filename); the page number within that source file (because a single PDF often contains multiple invoices, or one invoice spread across many pages); the ingestion timestamp (when the document entered the AP workflow); per-field extraction confidence where the capture step exposes it; the original filename as supplied (separate from the internal reference, retained because it is sometimes the only link back to the supplier's email or upload context); and a content hash where the AP record needs to prove that what was posted is what was received and nothing has been substituted since.

The bookkeeping decisions these fields serve are the ones that show up at the wrong moment. When a posting is questioned weeks or months later — by an external auditor, by a VAT inspector, by the supplier disputing a payment, or by an internal exception triage — the trace fields are what let the team reach the original document in seconds rather than spending half a morning navigating shared folders. When extraction is automated rather than manual, exposing per-field confidence on the posted record lets the team triage where to spot-check rather than treat every row as equally trustworthy or equally suspect; without it, the choice is to verify nothing or verify everything, and both are wrong. When documents arrive consolidated — multiple invoices in one PDF, or one invoice spread across pages 47 to 53 of a 200-page batch — the page-number reference is the only mechanism that anchors each posted record to its actual source pages.

The failure modes when audit-trace fields are absent are direct. The bookkeeper cannot find the source PDF for an invoice questioned at year-end, and the response time stretches from minutes to days, with the auditor watching the clock. A clean audit becomes a qualified one when the auditor flags that posted records cannot be reliably traced to their underlying documents. An automated capture system posts low-confidence extractions as if they were high-confidence because the confidence signal was discarded at the schema layer, and the resulting errors are invisible until they accumulate into a noticeable subledger break. Multi-page or multi-invoice PDFs lose the page-level anchor entirely when only a file-level reference is captured, and the team cannot prove which page of a 200-page consolidated PDF corresponds to which posted record.

The reason most field lists skip this category is structural. Vendor pages organize fields around what the extraction tool produces from the document; audit-trace fields are produced by the workflow around the tool — the intake step assigns the source-file reference, the extraction step assigns confidence, the posting step assigns the ingestion timestamp. None of them come off the invoice as a printed value. A schema that takes bookkeeping seriously has to include them anyway, because the absence shows up only when something goes wrong, by which time the document is harder to retrieve than it would have been with the trace attached at posting.

Normalization for audit-trace fields follows the same discipline as for the other categories, with category-specific rules. The source-file reference should be a stable internal identifier rather than a filename that may be renamed, moved, or re-uploaded; the file path on a given day is not a durable reference. Ingestion timestamps should be in a consistent timezone — UTC is the safe default — because the same captured moment will otherwise read differently across team members and audit periods. Extraction confidence should be expressed on a single consistent scale per schema (whether that is a 0–1 probability, a percentage, or a categorical low-medium-high) and not mixed across fields; an auditor or an exception-triage engine consuming the schema needs the scale to be uniform to act on it.

---

Captured vs Calculated, Smallest Effective Schema, and Document Boundaries

The five categories cover the field universe. Three cross-cutting decisions determine how that universe is sized and shaped — what to capture versus what to derive, when to stop adding fields, and how the schema interacts with documents that don't map cleanly to one logical invoice. These are also where the residual choices around how to normalize supplier invoice data live.

The first decision is the captured-versus-calculated line. Anything the supplier writes down on the invoice belongs in the captured fields, even when the team also intends to derive a calculated equivalent. Anything that is a function of captured fields — line-total cross-check (quantity multiplied by unit price tested against the printed line total), variance against the PO line, gross-equals-net-plus-tax three-way reconciliation, supplier-side currency conversion against the buyer's accounting currency — belongs in calculated fields, derived after capture rather than asked of the supplier or of the extraction step.

The rule behind the line is asymmetric. Capturing what should be calculated multiplies the error surface: the captured field can disagree with its inputs, and the team now has a reconciliation problem that did not have to exist — a data-quality problem the team owns and can fix in the schema layer. Calculating what should be captured produces wrong numbers when the supplier disagrees with the math; the derived line total no longer matches what the supplier is asking to be paid, the AP register diverges from the supplier statement, and a payment-correctness problem now runs straight into the supplier relationship. GL coding is the canonical case where the calculated treatment is right — coding rarely appears on a supplier invoice in usable form, and deriving it from captured fields (line description, supplier identity, cost-center hint) is what most teams do anyway. The dedicated piece on GL coding from captured invoice data walks through the derivation logic.

The second decision is what to leave out. Most surrounding content on this topic carries an implicit "more fields is better" bias because that is the product story for an extraction tool. The bookkeeping reality is the opposite. Extra fields that are not required by posting, matching, audit, or reporting logic do not improve bookkeeping; they create reconciliation work without a downstream decision to support, and they slow the team's exception triage because every captured field is one more thing that can be wrong. Capturing an optional field on every invoice in case it might be useful in the future trades certain operational friction now for hypothetical future value. The right schema is the smallest set of fields the team's actual posting, matching, audit, and reporting logic depends on — not the largest set the extraction step can produce.

The right way to test a candidate field is to ask which of the five categories' downstream jobs it serves. If a field is not required for posting, not required for matching, not required for the tax return, and not required for audit retrieval, it is not a schema field — it is noise the extraction step happens to be producing. The discipline is to leave it on the source document rather than promote it to the schema, and to revisit only when a downstream decision actually needs it.

The third decision is document boundaries. A single supplier invoice is sometimes one logical document spread across several PDF pages; sometimes several separate invoices in one PDF (consolidated supplier billing, scanned batches, monthly statements with attached invoices); sometimes an invoice attached to a statement of account where the schema should ignore the statement and capture the invoices; sometimes the same invoice received twice in two formats — once as a PDF attachment, once as the body of an email — and the duplicate has to be detected before either is posted. The schema decision depends on the document-boundary decision being made first, because every field the schema captures has to be tied to the right logical invoice. The page-number capture from the audit-trace category is what makes this work mechanically — without page-resolution anchoring, multi-invoice PDFs collapse into a single posted record or fragment unpredictably.

The cross-cutting decisions also determine where normalization lives. A captured field can be normalized at extraction (the date is converted to ISO at capture, the PO number has its leading zeros stripped before it lands in the schema) or at posting (the captured value is stored as-is and the AP register applies the cleanup before it commits). Both are valid; doing the work twice or doing it nowhere both produce errors. The choice determines whether the extraction step or the AP register owns the cleanup, and the answer should be deliberate rather than incidental — whichever owner has the more durable rule wins the responsibility.

---

Turning the Schema Into a Working Artifact

A schema is a decision, not an artifact. The artifact is whatever the team's downstream tools require, and the same five-category schema produces different artifacts depending on the path the team is on. A team using an AI extraction tool encodes the schema as an extraction prompt. A team importing into accounting software encodes it as a column mapping in a spreadsheet template. A team still entering invoices manually encodes it as a coding standard and a quality-check procedure. A team integrating programmatically encodes it as a structured field definition consumed via an API. The schema is what they all share; the artifact is how each team operationalizes it.

Each artifact has a recognizable shape. An extraction prompt encodes the schema as direct instruction to the extraction step — which fields, at what level, with what normalization expectations, with which fields derived rather than captured. A CSV or XLSX import template encodes it as columns the accounting system ingests, with the column order and naming determined by the receiving system rather than the supplier's invoice layout. A coding standard for manual entry encodes it as a procedure document plus a quality-check process — the standard names the fields and the rules, and the procedure ensures the rules are applied uniformly across team members. An API or SDK integration encodes it as a structured field definition consumed programmatically. The supplier invoice schema for AP that gets agreed in a meeting and then forgotten in a folder is not yet an artifact; the artifact is what happens to the schema once the team commits it to the tool that consumes it.

Prompt-driven extraction is the path where the schema decisions made earlier in this article become the literal instruction. The five-category structure is what the prompt expresses — header fields, line-level detail, control and matching, tax and compliance, audit-trace. The normalization expectations (dates as ISO, currencies as ISO 4217 codes, PO numbers cleaned, invoice numbers canonicalized) are what the prompt enforces field by field. The captured-versus-calculated split tells the prompt which fields to ask for and which to derive afterwards. This is also where the automate supplier invoice data extraction workflow earns its place: the schema is the configuration, expressed once as a prompt and reused across every batch, so the same five-category structure produces the same structured output whether the batch is ten invoices or ten thousand.

The mechanics on the prompt side match the discipline on the schema side. A saved AP month-end-close prompt names the fields and the rules inline — date format, default tax handling, credit-note treatment, page filtering — and lives in a prompt library so it gets reused rather than re-litigated every month. Normalization rules sit inside the prompt because that is where the schema decisions belong: the same rules apply to every supplier in every batch, regardless of how they print their invoices.

The closing point is operational. A finance team that has decided on its schema using the five-category framework can encode it directly into whichever artifact the workflow needs. The decision work is upstream of the tooling, and the tooling — whether that is a prompt, a template, a coding standard, or an API contract — is downstream of the schema rather than the other way around. The mistake the SERP makes is to invert that order, presenting the tool's field list as the schema; the better order is to make the schema decisions first, by category, against the bookkeeping jobs each category serves, and then encode the result.