Many Italian and B2B-focused stores need more than Magento's default address fields — think Fiscal Code, PEC email, or an SDI code. This guide shows how to add custom fields to Magento 2 address forms natively, using Magento's own EAV system, so the new fields appear automatically in the admin, the customer account, and checkout.
- Create a custom EAV attribute on the
customer_addressentity via a Data Patch - Make the new field appear automatically in My Account, checkout, and the admin order/customer grid
- Apply validation rules (required, email format, regex) without third-party code
- Know the common pitfalls that make custom address fields silently disappear
Step 1: Plan the attributes you need
Before touching any code, list the fields precisely. For example:
fiscal_code— text, max 16 characterspec_email— text, validated as emailsdi_code— text, max 7 characters
type or code alone — this avoids silent conflicts with core EAV columns. Step 2: Scaffold a custom module
Create a minimal module under app/code/Vendor/AddressFields.
app/code/Vendor/AddressFields/registration.php
app/code/Vendor/AddressFields/etc/module.xmlmodule.xml only needs the module name and setup version — no dependencies beyond Magento_Customer.
<module name="Vendor_AddressFields" setup_version="1.0.0">
<sequence>
<module name="Magento_Customer"/>
</sequence>
</module>Step 3: Write the Data Patch
Add a class implementing DataPatchInterface under Setup/Patch/Data/AddFiscalFields.php. Inside it, use Magento\Customer\Setup\CustomerSetupFactory to create each attribute on the customer_address entity.
Key settings per attribute:
type::varcharinput::text(orselectfor a dropdown)visible::truerequired::false(set totrueonly if the field must always be filled)used_in_forms::['adminhtml_customer_address','customer_address_edit','customer_register_address','customer_address_form']
used_in_forms does not include customer_address_edit and customer_register_address, the field will be invisible on the storefront even though it exists in the database. Step 4: Apply the patch
Run the setup commands from the Magento root:
bin/magento setup:upgrade
bin/magento cache:flushMagento registers the patch in the patch_list table so it only runs once, even across deployments.
Step 5: Verify the field in the Admin
Open any customer and go to the Addresses tab.
If it's missing, re-check used_in_forms includes adminhtml_customer_address and clear the cache again.
Step 6: Confirm it appears on storefront forms
Because Magento's checkout and My Account address forms are built dynamically from EAV metadata, no template edits are required for simple text fields.
The same attribute also appears automatically in checkout:
customer_address attributes into the checkout UI component through its own AttributeMerger service — this is the same native mechanism that powers the built-in Company and VAT Number fields. Step 7: Add validation rules
For an email-style field like PEC, set the attribute's input_validation to email inside the data patch ('validate_rules' => ['input_validation' => 'email']). For fixed-length codes like SDI, use a frontend_class of validate-length combined with data-validate attributes in a small layout XML override if you need a regex check.
Step 8: Translate the labels
If the store serves multiple languages, add the attribute labels to the store's CSV dictionary.
Step 9: Test end to end
- Register a new customer and fill in all new fields
- Place a test order as a guest and as a logged-in customer
- Check the field values appear in the admin order view under the address details
- Export orders to confirm the new attributes are included if you added them to the grid
Checklist
- ☐ Attribute codes and types planned in advance
- ☐ Custom module created with a Data Patch, not direct SQL
- ☐
used_in_formsincludes admin, account, and checkout contexts - ☐
setup:upgradeandcache:flushrun after every patch change - ☐ Validation rules set for required or formatted fields
- ☐ Labels translated for every active store view
- ☐ Full checkout and My Account flow tested as guest and logged-in customer
Common mistakes
Attribute doesn't show on checkout. The used_in_forms array is missing customer_address_edit or the related checkout form key — add it and re-run the patch logic (or write a follow-up patch).
Field shows but can't be edited after saving. The attribute may be missing is_used_for_customer_segment or has an incorrect source_model for select-type fields — double check the input type matches the frontend input.
Duplicate attribute errors on deploy. Someone ran the patch manually via a script instead of bin/magento setup:upgrade, bypassing the patch_list tracking table. Always deploy through the standard command.
Validation ignored on checkout. Validation rules set only via admin templates don't propagate to the checkout UI component — they must be defined on the attribute itself in the data patch.
FAQ
Can I add these fields without writing any code?
Not through core Magento admin screens alone — address attributes require a data patch. Dedicated extensions exist specifically to add this kind of fiscal field without development work.
Will the new fields work for guest checkout too?
Yes, as long as the attribute's used_in_forms includes the relevant checkout form key. Guest and logged-in checkout share the same EAV-driven address component.
Can I make a field required only for business customers?
Native Magento doesn't support conditional required logic per customer type out of the box — you'd need custom JavaScript or a dedicated module that toggles validation based on a customer type selector.
Do these custom fields appear on invoices and PDFs automatically?
No, PDF templates must be edited separately to pull in the new attribute values; adding the field to forms and adding it to printed documents are two different tasks.
A faster alternative
Building and maintaining a custom module for Italian B2B fiscal fields — VAT number, Codice Fiscale, PEC, and SDI — takes real development time and ongo
