Stop NetSuite Formatting Integers with Commas

You create a custom integer field for street numbers, save the record, and NetSuite displays 1,234 instead of 1234. The commas are baked into the field's default display behavior, there's no "remove commas" button on the record itself. The fix lives in the field definition, not the record view.

The Display Setting That Controls Commas

Every numeric custom field (Integer, Decimal, Currency) includes a Format Number checkbox on the Display subtab. When checked, which is the default, NetSuite applies the user's locale formatting: commas for thousands separators, periods for decimals in US/UK locales. Unchecking it forces raw digit display.

Exact navigation:

1. Go to Customization > Lists, Records, & Fields > [Record Type] Fields (e.g., Entity Fields for Customer/Vendor, or Transaction Body Fields for Sales Orders)
2. Edit the integer field
3. Click the Display subtab
4. Uncheck Format Number
5. Save

The change takes effect immediately on existing records, no cache clear or re-login required.

The Format Number checkbox controls only presentation. The stored value remains an integer; searches, formulas, and SuiteScript see 1234 regardless.

Why Integer Fields Default to Formatted Display

NetSuite assumes numeric fields represent quantities, amounts, or counts, values where thousands separators aid readability. The platform doesn't distinguish "quantity" from "identifier" at the field-type level. An integer field tracking quantity_on_hand benefits from 1,234; an integer field tracking street_number does not.

This trips people up because the field creation flow doesn't surface the display option. You pick Integer, set the label, save, and only later notice the commas on the record.

The Street Number Trap: Integer vs. Text

The Reddit thread that sparked this article reveals a deeper design question: should street numbers be integers at all?

If your addresses are strictly numeric (US suburban grids), the integer field with Format Number off works. The moment you encounter 1/2, A, B, or 123-45, the integer field becomes a liability.

Enforcing Numeric-Only Input on a Text Field

If you choose Free-Form Text to accommodate global formats, add a client script to restrict input to digits only:

/**
 * @NApiVersion 2.1
 * @NScriptType ClientScript
 */
define(['N/error'], (error) => {
    function validateField(context) {
        const fieldId = 'custentity_street_number'; // your field ID
        if (context.fieldId !== fieldId) return true;

        const value = context.currentRecord.getValue(fieldId);
        if (value && !/^\d+$/.test(value)) {
            alert('Street number must contain digits only.');
            return false;
        }
        return true;
    }
    return { validateField };
});

Deploy to the relevant record types (Customer, Vendor, Contact). The regex ^\d+$ allows only one or more digits, no spaces, dashes, letters, or fractions. Adjust the pattern if you need to allow suffixes (^\d+[A-Za-z]?$).

Search and Formula Implications

Unchecking Format Number does not change how the field behaves in:

• Saved Searches: Results show raw digits; the "Number" format option in the search column still adds commas unless you override it
• SuiteQL: SELECT custentity_street_number FROM customer returns 1234
• Formula (Numeric) fields: TO_CHAR({custentity_street_number}) yields '1234', no commas unless you explicitly format with TO_CHAR({custentity_street_number}, '999,999')

If you build a saved search for export and need commas there, use the search column's Number Format dropdown → Custom → #,##0. The field definition and the search output are independent.

Quick Checklist Before You Decide

• [ ] Are all current and future addresses strictly whole numbers?
• [ ] Do you need leading zeros preserved (e.g., 00123)?
• [ ] Will this field ever feed a mapping API or shipping label generator?
• [ ] Can you accept a client script deployment for validation?

If any answer is "no," use Free-Form Text with validation. The integer field is a convenience for quantities, not identifiers.

One More Thing: Currency Fields Behave Differently

Currency fields always format with the locale's currency symbol and separators. There is no Format Number checkbox on the Display subtab for Currency type, instead, a Currency Context subtab appears to define the associated currency. If you need a raw numeric amount without $ or commas, use a Decimal field with Format Number unchecked, or a Free-Form Text field with a stricter regex (^\d+(\.\d{1,2})?$).

Need to clean up custom fields that have outlived their purpose?