---
id: ADR-ACC-TRX-007
title: No Custom Fields on Financial Records
product_area: accounting
module: transactions
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  The recorded custom-field opt-in policy gives transaction records no custom
  fields; invoice caller metadata remains source context, while explicit
  registration conformance is unverified.
constrains:
  - DOM-ACC-TRX-001
  - DOM-ACC-TRX-003
  - DOM-ACC-TRX-004
  - DOM-ACC-TRX-005
  - DOM-ACC-TRX-006
  - RESP-ACC
origin: >-
  R2-ARCH-001 approved by Andrew on 2026-10-19 (custom fields opt-in per entity,
  none for Accounting), recorded in
  services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#Entity
  capabilities (R2-ARCH-001)
alternatives:
  - option: Enable arbitrary custom values on billing and receipts.
    why_not: >-
      The recorded opt-in decision does not select Accounting records for that
      capability.
  - option: Treat caller metadata as staff-editable custom fields.
    why_not: >-
      The source owns that context, and its limited interpretation does not
      provide a customization contract.
consequences:
  - >-
    Transaction storage and exports do not provide a custom-value mechanism; the
    module registration also lacks an explicit custom-field declaration.
  - >-
    Caller metadata is size-bounded and retained as supplied for its source
    context.
supersedes: []
evidence:
  - >-
    services-accounting at f47cb263:
    docs/milestones/ACCT-M1-books-and-invoices.md;
    docs/milestones/plans/ACCT-M2-plan.md §7a;
    modules/transactions/aws/api/invoices.schemas.ts
    (invoiceCustomMetadataSchema).
---
# No Custom Fields on Financial Records

## Context

The evidence supports absence of transaction custom-field storage. It does not show an explicit capability flag in the current module registration.

## Decision

The structured decision records the governing boundary and its observed limits. Its origin distinguishes Andrew’s rulings from reversible implementation choices and proposed publication policy.

## Alternatives Considered

The listed alternatives explain the competing responsibility or recovery approaches and why the recorded direction differs. They are explanatory comparisons, without evidence of a separate approval discussion for each alternative.

## Consequences

The consequence rows identify implementation obligations, current departures and gaps requiring further verification. Artifact status remains proposed until Andrew approves it.