NUMERIC stores decimal amounts with a declared precision and scale. In NUMERIC(12,2), 12 is the total number of significant digits and 2 is the number of decimal digits. This fits ACH credit and debit totals, where the database structure should closely reflect the defined amount field. section 5.1
Choosing NUMERIC is also a data-quality decision. An amount stored as VARCHAR can retain spaces or other malformed characters, while a NUMERIC column makes the database enforce numeric input. That enforcement can expose existing parsing or workflow problems, so tests should identify the adjustments needed. section 7.3
Listing 7.3 ACH table for the file control record
total_debit_entry_dollar_amount NUMERIC(12, 2) NOT NULL, total_credit_entry_dollar_amount NUMERIC(12, 2) NOT NULL,
The file-control table declares debit and credit totals as required NUMERIC(12,2) columns, making the intended monetary shape explicit at storage time. section 7.3
A reliable amount flow keeps the same meaning across layers:
- Parse fixed-width whole and fractional portions into Decimal values before persistence. section 7.3
- Store debit and credit totals in NOT NULL NUMERIC(12,2) columns. section 7.3
- Return Decimal totals in the API response model and map the API field names to UI fields. section 7.3
Storing an ACH total
An ACH record can provide an amount in separate fixed-width whole-dollar and cent slices. Build a decimal value from those slices, then save it to total_debit_entry_dollar_amount or total_credit_entry_dollar_amount as NUMERIC(12,2). The API can expose the resulting debit_total and credit_total for display. section 7.3 section 5.1
