How to Generate E2B(R3) XML for FAERS/AEMS Submission: A Complete 2026 Guide

If you're a pharmacovigilance operations engineer, a regulatory affairs lead at a small biotech, or anyone responsible for getting ICSRs out the door to FDA — and the October 1, 2026 deadline is on your mind — this guide is for you.

We'll cover what E2B(R3) actually is, how an ICSR is structured, where reports get rejected, how to validate before submission, and what the migration from E2B(R2) to E2B(R3) actually involves. The technical depth is real; if you're new to ICSRs, our companion guide on how to fill out FDA Form 3500A is the better starting point.

One-paragraph summary: E2B(R3) is the current ICH standard for electronic transmission of Individual Case Safety Reports. It uses HL7 v3 XML messages, has 330+ data elements, and replaces the simpler E2B(R2) format. FDA mandates E2B(R3) for postmarketing ICSRs starting October 1, 2026. Generating valid XML means clearing four layers of validation: XML well-formedness, XSD schema, ICH business rules, and FDA's regional rules. Most rejection happens at the last two layers, and most of those rejections are caused by missing nullFlavors on fields that have no real value to ship.

The 2026 landscape

A few facts worth knowing before going further:

FAERS is now AEMS. On March 11, 2026, FDA renamed the FDA Adverse Event Reporting System (FAERS) to the Adverse Event Monitoring System (AEMS) and consolidated it with VAERS (vaccines), MAUDE (devices), and the food/cosmetic/animal reporting systems. The submission gateway and the XML format are unchanged. You still send ICSRs through ESG NextGen using E2B(R3) XML. But if you're searching for "FAERS submission" today, half the official documentation has been renamed.

E2B(R3) deadline: October 1, 2026. FDA had originally set April 1, 2026, then extended by six months in April 2026. After September 30, 2026, postmarketing ICSRs in E2B(R2) format will be rejected. Premarketing IND safety reports and IND-exempt BA/BE reports already require E2B(R3) — that transition happened in 2024.

No going back. Once you submit your first ICSR in E2B(R3), you cannot revert to E2B(R2) for subsequent submissions from the same sender. This is FDA's "no-reversion" policy. Plan your cutover accordingly.

The current technical authorities: - ICH E2B(R3) Implementation Guide (the international spec) - FDA Regional Implementation Guide for E2B(R3), August 2024 version - FDA E2B(R3) Core and Regional Data Elements and Business Rules, v1.6 (January 2024) - FDA E2B(R3) Forward Compatible Rules (April 2022)

These four documents together describe what a valid E2B(R3) ICSR looks like for FAERS/AEMS. Plan to read them once cover-to-cover.

What E2B(R3) actually is

E2B(R3) is the third revision of the ICH (International Council for Harmonisation) standard for electronic transmission of Individual Case Safety Reports. It defines two things:

A data model. What data goes in an ICSR, organized into seven main sections (C, D, E, F, G, H, plus header section N).
A wire format. HL7 v3 XML messages that carry the data over the network.

The key difference from E2B(R2):

E2B(R2) was flat. Each ICSR was an XML document with a relatively shallow structure, derived from an older SGML standard. About 270 data elements. Simple to read, simple to debug, but limited in expressiveness — partial dates were awkward, repeating groups were limited, and many fields were free text where structure would have been more useful.

E2B(R3) is hierarchical. It uses the HL7 v3 Reference Information Model (RIM), which means everything is wrapped in classes (investigationEvent, adverseEventAssessment, observationEvent, etc.) and connected by class-code/mood-code attributes. About 330 data elements. More expressive, more structured, more verbose. The same case in R3 is 2-4x larger than in R2.

The verbosity isn't gratuitous. It enables things R2 couldn't do cleanly:

Per-reaction granularity. Each reaction has its own seriousness BL flags, its own outcome, its own MedDRA term. R2 forced these into a single block per case.
NullFlavors on required fields. R3 lets you ship a "required" element without a value by attaching a nullFlavor attribute explaining why. R2 mostly forced senders to invent placeholder values.
Better repeating groups. Multiple suspect drugs, multiple reactions, multiple sources of report — each cleanly modeled.

The cost is complexity. Hand-writing a valid E2B(R3) XML from scratch is hours of work; hand-debugging one is days. Tooling is essentially mandatory.

Anatomy of an ICSR

An E2B(R3) ICSR is one XML document containing one or more ICSRs in a batch wrapper. The structure looks like this (heavily abbreviated):

<?xml version="1.0" encoding="UTF-8"?>
<MCCI_IN200100UV01 xmlns="urn:hl7-org:v3">

  <!-- Section N.1: Batch header -->
  <id extension="BATCH-12345" root="2.16.840.1.113883.3.989.2.1.3.22"/>
  <creationTime value="20260601120000"/>
  <responseModeCode code="D"/>
  <interactionId extension="MCCI_IN200100UV01" root="2.16.840.1.113883.1.6"/>
  <name code="1" codeSystem="2.16.840.1.113883.3.989.2.1.1.1"
        codeSystemVersion="1.01"/>

  <!-- Section N.2: Message header -->
  <PORR_IN049016UV>
    <id extension="MSG-67890" root="2.16.840.1.113883.3.989.2.1.3.1"/>
    <creationTime value="20260601120000"/>
    <interactionId extension="PORR_IN049016UV" root="2.16.840.1.113883.1.6"/>
    <processingCode code="P"/>
    <processingModeCode code="T"/>
    <acceptAckCode code="AL"/>

    <!-- Sender and receiver devices -->
    <receiver typeCode="RCV">
      <device classCode="DEV" determinerCode="INSTANCE">
        <id extension="FDA" root="2.16.840.1.113883.3.989.2.1.3.12"/>
      </device>
    </receiver>
    <sender typeCode="SND">
      <device classCode="DEV" determinerCode="INSTANCE">
        <id extension="123456789" root="1.3.6.1.4.1.519.1"/>
      </device>
    </sender>

    <!-- The actual ICSR content -->
    <controlActProcess classCode="CACT" moodCode="EVN">
      <subject typeCode="SUBJ">
        <investigationEvent classCode="INVSTG" moodCode="EVN">
          <!-- Sections C, D, E, F, G, H all live in here -->
        </investigationEvent>
      </subject>
    </controlActProcess>
  </PORR_IN049016UV>
</MCCI_IN200100UV01>

What's in each section:

N.1 — Batch header. Identifies the batch (a single transmission can carry one or many ICSRs), when it was created, and what kind of message it is.
N.2 — Message header. Sender ID, receiver ID, processing parameters. For FAERS, the receiver is always FDA with OID 2.16.840.1.113883.3.989.2.1.3.12. The sender's DUNS number with OID 1.3.6.1.4.1.519.1 is the most common identifier (more on this below).
C — Identification of the ICSR. Case ID, dates, message type (initial / follow-up / nullification), sender info.
D — Patient characteristics. Age, sex, weight, race, ethnicity, medical history, parent info (for pediatric cases).
E — Reactions/Events. One per reaction — MedDRA-coded, with seriousness BL flags, outcome, time of onset.
F — Tests and procedures. Lab results, ECGs, imaging — anything diagnostic.
G — Drugs. One per drug — name, dose, route, frequency, dechallenge/rechallenge, role (suspect/concomitant/interacting).
H — Case narrative. Free-text description of the case, plus any additional documents available flag.

Every E2B(R3) data element has an identifier of the form <section>.<number> (e.g., D.2.1 for date of birth, E.i.1.1a for reaction text). FDA's regional additions use the FDA. prefix (e.g., FDA.D.11.r.1 for race code with US-specific value set).

The validation pipeline

This is where most submissions fail. Understanding it is the difference between debugging a rejection in minutes and debugging it in days.

When you submit an E2B(R3) ICSR to FAERS/AEMS, it's checked at four progressively stricter layers:

Layer 1: XML well-formedness

The XML must parse. Mismatched tags, broken character escapes, invalid characters in element content — these get rejected before any business logic runs. Errors look like:

Premature end of file at line 245
Element type "telecom" must be followed by either attribute specifications, ">" or "/>"

If your XML is generated by code, this layer is usually clean — the XML libraries handle well-formedness. If you're hand-editing XML for a one-off case, this is where you'll trip first.

Layer 2: XSD schema validation

The XML must match the structural schema published by HL7/ICH. This catches:

Required elements missing or in wrong order
Attributes with wrong data types (string where date expected, etc.)
Invalid attribute values for closed vocabularies (responseModeCode must be D or I, not anything else)

Errors look like:

cvc-datatype-valid.1.2.1: 'mailto:' is not a valid value for 'anyURI'.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'effectiveTime'.

A subtle pitfall here: nullFlavored elements sometimes need a placeholder value attribute to satisfy the schema, but the placeholder must itself be valid. We've seen production emitters ship <telecom nullFlavor="NASK" value="mailto:"/> — schema rejects this because mailto: (with empty body) is not a valid anyURI. The fix is <telecom nullFlavor="NASK" value="mailto"/> (no colon).

Layer 3: ICH and FDA business rules

This is where most production rejections happen. The rules go beyond schema — they encode "if X is true, then Y must also be true" constraints. Examples from the FDA Core and Regional Business Rules document:

R0020: If C.2.r.5 (Primary Source for Regulatory Purposes) is set to 1, then C.2.r.3 (Reporter Country) must be present.
R0022: If C.3.1 (Sender Type) is not 7 (Patient/Consumer), then C.3.2 (Sender Organization) must be present.
N.1.1: The batch type code must be 1 (corresponding to display label ichicsr).

The FAERS LSMV validator (more on this below) returns rejection codes like FDA-VR-C.2.r.4-001 that map back to specific rules.

The trick: many of these business rules are conditional, and the condition can be satisfied by a nullFlavor rather than a real value. The validator's job is to check whether you supplied either a real value or a permitted nullFlavor. Get that nullFlavor logic wrong in your emitter and you'll see a rejection on every case.

Layer 4: Acknowledgment processing

After your XML clears layers 1-3, FAERS/AEMS returns acknowledgments through the gateway:

ACK1: Gateway received the file. Generated within minutes.
ACK2: File passed initial gateway validation (schema, basic structure). Generated within hours.
ACK3: Business rule validation result. Either accepted (positive ACK) or rejected (negative ACK with specific error codes). Generated within hours to a day.

If you don't get an ACK3 within 48 hours, something is wrong on the gateway side. Contact FDA's ESG support.

NullFlavors: the unintuitive part

If there's one concept that gets E2B(R3) implementers stuck, it's nullFlavors. They're HL7 v3's solution to "we know this field is required but we don't have a value to put in it" — and they're often where the difference between rejection and acceptance lives.

The six relevant nullFlavor codes:

Code	Meaning	When to use
`NI`	No information	Default "no info available". Generic catch-all.
`UNK`	Unknown	The value exists conceptually but we don't know what it is.
`ASKU`	Asked but unknown	We tried to find out and couldn't (e.g., asked the patient, patient didn't know).
`NASK`	Not asked	We didn't try to find out (e.g., never asked the patient).
`MSK`	Masked	Information exists but is being withheld for privacy/security reasons.
`NA`	Not applicable	The field doesn't apply (e.g., last menstrual period for a male patient).

The hard part: each E2B(R3) data element has its own list of permitted nullFlavors. You can't just slap UNK on anything required. The rulebook specifies, per element, which nullFlavors are acceptable.

Examples from the FDA business rules:

C.2.r.3 (Reporter Country): UNK is allowed.
C.2.r.4 (Reporter Qualification): UNK is allowed.
FDA.C.2.r.2.8 (Reporter Email): MSK, ASKU, NASK are allowed. UNK is not.
D.1 (Patient Name/Initials): MSK, ASKU, NASK, UNK are allowed.
FDA.D.11.r.1 (Patient Race): NI is allowed (specified by FDA regional rules).
D.5 (Patient Sex): Per ICH Q&A, MSK, UNK, ASKU, NASK are allowed (the IG itself says only MSK but the Q&A document, which supersedes, expands this).

The decision tree most reporters end up using:

Do you know the value? Use the value.
Was the value sought but unavailable? ASKU.
Was the value never sought? NASK.
Is the value known but withheld for privacy? MSK.
Is the field genuinely not applicable to this case? NA.
None of the above and you just don't know? UNK (or NI if UNK isn't permitted).

A common emitter bug we've seen: code that defaults every missing field to nullFlavor="NI" regardless of what the rulebook permits for that specific element. FAERS will reject most of those reports because NI is broadly permitted in the ICH guide but FDA narrows it for several US elements. The fix is per-element nullFlavor selection driven by the rulebook, not a global default.

Special case: the `<telecom>` mailto trap

Worth its own subsection because it catches almost every new implementer.

The <telecom> element carries phone, fax, and email values. The value attribute is a URI: tel:+1-555-1234, fax:+1-555-5678, mailto:contact@example.com.

When you don't have a real email and want to ship a nullFlavor instead, the temptation is:

<telecom nullFlavor="NASK" value="mailto:"/>

This fails XSD validation because mailto: (the scheme with an empty body) isn't a valid anyURI.

The correct form per FAERS guidance:

<telecom nullFlavor="NASK" value="mailto"/>

Note: no colon. mailto alone is a valid token but not a structured URI, which is exactly what FAERS wants here — the value attribute signals "this is an email telecom slot" while the nullFlavor says "no actual email available."

We have seen FAERS LSMV return both:

Reporter's Email (FDA.C.2.r.2.8) is mandatory and must be in the format of telecom value='mailto:email@address.com' or telecom nullflavor='NASK' value='mailto'

confirming the colon-less form is the accepted convention.

Sender identification: the OID and the DUNS number

For FAERS submission, your sender ID must be an FDA-recognized identifier. The most common choice:

DUNS Number (9-digit Dun & Bradstreet identifier)
With OID 1.3.6.1.4.1.519.1

In XML:

<sender typeCode="SND">
  <device classCode="DEV" determinerCode="INSTANCE">
    <id extension="123456789" root="1.3.6.1.4.1.519.1"/>
  </device>
</sender>

A non-DUNS identifier requires FDA pre-approval. ICSRs with unrecognized sender identifiers are rejected at the gateway before reaching the business-rule layer.

The receiver, for FAERS postmarketing, is always:

<receiver typeCode="RCV">
  <device classCode="DEV" determinerCode="INSTANCE">
    <id extension="FDA" root="2.16.840.1.113883.3.989.2.1.3.12"/>
  </device>
</receiver>

For premarketing (IND safety reports), the receiver changes to CDER_IND, CBER_IND, or CDER_IND_EXEMPT_BA_BE depending on the application type, with the same OID structure but using receiver OID 2.16.840.1.113883.3.989.2.1.3.14. The batch receiver identifier in N.1.4 also differs: ZZFDA for postmarketing, ZZFDA_PREMKT for premarketing.

Getting these wrong is a common cause of rejection that's easy to fix once identified.

Validating before you submit

Before sending anything to FAERS, validate locally. There are four tools worth knowing:

1. FDA's LSMV validator (free, official)

FDA hosts a public E2B(R3) validator at:

https://faers-validator.fda.gov/LSMV/Validator

Upload your XML, get back a validation report. It runs FDA's actual business rules — what you see here is what FAERS would see at submission time. Caveats:

It's not a documented public API. There's no SLA and no guarantee of uptime. We've seen it return 503 Service Temporarily Unavailable for hours at a stretch.
It's interactive — designed for human submitters checking a file before submission, not for automated pipelines hammering it on every export.
Rate limits are undocumented. Use it sparingly.

Despite the caveats, this is the authoritative free check. If LSMV accepts your XML, FAERS will (probably) accept it. If LSMV rejects, FAERS definitely will.

2. XSD schema validation (free, programmatic)

The HL7 v3 schema files for MCCI_IN200100UV01 and the related PORR_IN049016UV are available from HL7 and from FDA. Run your XML against them with any standard XML library:

from lxml import etree
schema_doc = etree.parse('MCCI_IN200100UV01.xsd')
schema = etree.XMLSchema(schema_doc)
doc = etree.parse('my-icsr.xml')
schema.assertValid(doc)

This catches Layer 2 errors but not Layer 3 (business rules). Schema-valid XML still routinely gets rejected for business rule violations.

3. Open-source business rule checkers

A few open-source projects implement the ICH/FDA business rules in code:

The FDA published FDA E2B(R3) Core and Regional Data Elements and Business Rules as a structured document — some teams have parsed it into machine-readable rule sets and shipped open-source validators.
The e2b-r3-validator GitHub project (and similar) implements a subset of the rules.

These are useful but generally don't keep pace with FDA's rule revisions, so they catch the common errors and miss the rare ones.

4. Commercial validators

Enterprise PV platforms (Oracle Argus, Veeva Vault Safety, ArisGlobal LifeSphere) include their own E2B(R3) validators. If you're using one of these, validation is part of the workflow.

What happens when you try to generate this yourself

This is where the friction lives. The four typical paths people take:

Path A: From scratch

Write XML generation code that emits the full ICSR structure based on case data. Realistic effort: 6-12 months for one engineer to get to production-ready quality. Most of the time is spent on edge cases — partial dates, nullFlavor selection, repeating groups, MedDRA coding, validation.

Path B: Extend an existing safety database

If you have Oracle Argus, Veeva Safety, or similar, they have built-in E2B(R3) modules. You configure mappings between your database fields and E2B elements, run their validator, and submit. Realistic effort: weeks to months for the configuration, plus the cost of the platform itself (typically $50k-$500k+ per year for the larger systems).

Path C: Hand-write XML per case

For very low volume — a few cases a year — some small biotechs hand-write XML using a template, validate with FDA's LSMV, and submit. Realistic effort per case: 4-8 hours, very error-prone. Only viable if your volume is genuinely low.

Path D: Use a focused tool

Small dedicated tools that take case data (manually entered or extracted from a source) and emit valid E2B(R3) XML. Realistic effort: minutes per case after a one-time setup. Cost varies; some have free tiers.

The right path depends on your volume, your existing infrastructure, and your appetite for either build effort or platform cost. For most companies generating fewer than ~500 ICSRs per year, paths C and D dominate over A and B on cost-benefit.

A note from AdverseEvent.ai: If you're in the position of needing to generate E2B(R3) XML and you don't want to build a full pipeline or buy an enterprise PV suite, our tool sits in Path D. Upload a scanned 3500A, a research paper, or paste intake notes; the tool extracts the case data, lets you review every field, runs the same rulebook validator FAERS uses (LSMV when it's up, plus a local mirror), and produces a schema-valid E2B(R3) XML for download. FAERS analytics is free for everyone, no signup. The XML generation is a paid product starting at $99/month. Mentioning it once so we're not being coy.

Common rejection patterns

From production submissions across multiple senders, the recurring rejection causes:

Header issues (N.1, N.2)

N.1.1 wrong code. The batch type code must be 1 with codeSystem="2.16.840.1.113883.3.989.2.1.1.1". We've seen emitters ship code="ichicsr" (using the display label) instead, which fails. The rulebook lists this as 1=ichicsr (code 1, label "ichicsr") and the code is what goes in the XML.
Sender ID with wrong OID. Using a DUNS number with a different OID, or using a different identifier without FDA approval.
Batch and message receiver identifiers don't match the submission type. ZZFDA for postmarketing, ZZFDA_PREMKT for premarketing; getting this reversed rejects the batch.

Identification (C section)

C.1.1 not unique. The Sender's Safety Report Unique Identifier must be unique per sender per case. Resubmissions of the same case must reuse the same C.1.1; new cases must get a new one.
C.1.8.1 (Worldwide Unique Case Identifier) missing or malformed. This is the global tracking ID. Format: <country>-<company>-<report number>, all three segments mandatory, dash-separated.
C.2.r.3 missing when reporter is primary source. Rule R0020. If you set C.2.r.5=1, you must supply a country (or a permitted nullFlavor).
C.3.2 (Sender Organization) missing. Rule R0022. Sender types other than 7 (Patient/Consumer) require this.

Patient (D section)

No patient data at all. D section must contain at least one element (age, DOB, sex, weight) — or appropriate nullFlavors. A completely empty patient block is rejected.
Inconsistent age and DOB. If you supply both and they disagree by more than expected variance, it's flagged (typically as a warning, not a rejection, but worth fixing).
D.5 (Sex) with nullFlavor="NI". NI isn't on D.5's allowed list. Use UNK or ASKU instead.

Reactions (E section)

No reaction at all. Every ICSR must have at least one reaction. The <adverseEventAssessment> element must contain at least one reaction observation. An empty <adverseEventAssessment> block rejects the ICSR.
Reaction without MedDRA code. E.i.2.1b (LLT code) is required for each reaction. The verbatim text (E.i.1.1a) is also required but separately — both must be present.
Reaction without seriousness BL flags. Each reaction needs at least one E.i.3.2 seriousness flag (true or with a permitted nullFlavor). Missing all of them rejects.

Drugs (G section)

No drug at all. Every ICSR must have at least one drug. G.k.1 (Characterisation of Drug Role) is required.
G.k.2.2 (Medicinal Product Name) missing. For each drug, the product name is required.
G.k.2.1.1 (MedDRA term for indication) missing when G.k.7.r.2 is populated. Conditional rule.

Narrative and case summary (H section)

H.1 (Case Narrative) missing or empty. Required for all post-market cases. A common implementer bug: emitting an empty <text/> element. Empty doesn't satisfy "present"; either supply real narrative text or skip the element entirely (which fails its own required-element check). Real text or appropriate handling is the answer.

Schema-level issues

Invalid anyURI values. Most often the mailto: trap on telecom elements.
Invalid date formats. E2B(R3) dates use ISO 8601 (YYYY-MM-DD or YYYYMMDD). The 3500A dd-mmm-yyyy format is for human display only; in XML it gets converted.
Wrong codeSystem OID. Each value-set has a specific OID. Using ICH OIDs where FDA expects FDA OIDs (or vice versa) rejects.

Migrating from E2B(R2) to E2B(R3)

If you've been submitting in R2 and need to be R3 by October 1, 2026, the migration involves:

1. Map your data elements

R2 had ~270 elements; R3 has ~330. Most R2 elements map directly to R3 equivalents, but:

Some R2 fields are split into multiple R3 fields (e.g., R2's flat "reaction" gets a structured outcome and seriousness per reaction in R3).
Some R3 fields have no R2 equivalent and need to be populated from new sources.
Some R2 fields are deprecated and dropped in R3.

FDA publishes "Forward Compatible Rules" (April 2022) that describe how to interpret an R2 message as if it were R3, for senders staying on R2 during the transition. Reading this document gives you the mapping in reverse.

2. Decide your XML emission strategy

Three options:

Replace your R2 emitter wholesale. Cleanest but biggest engineering effort.
Run R2 and R3 in parallel during the transition. More effort but allows gradual rollout.
Add an R2→R3 conversion layer to your existing emitter. Fastest to ship but accumulates technical debt; the resulting R3 messages may have subtle deficiencies that R2 didn't surface.

Most teams end up doing some version of the third option for the deadline, then refactoring toward the first over the following year.

3. Validate, validate, validate

After every code change to your emitter, run a regression test suite against FDA's LSMV (or a local mirror). The rulebook is large enough that breaking a previously-passing case is easy.

4. Plan your cutover

FDA recommends doing test submissions through ESG's pre-production environment before production cutover. The pre-production environment runs the same validators but doesn't enter ICSRs into the production AEMS database.

The cutover itself is one-way per sender. Once you submit your first production R3 ICSR from a sender ID, that sender is committed — you can't go back to R2 for subsequent cases.

Submission paths: ESG NextGen and Safety Reporting Portal

Two ways to actually transmit your E2B(R3) XML to FAERS/AEMS:

Option A: ESG NextGen (Electronic Submissions Gateway, NextGen)

For senders with database-to-database transmission capability. You configure either WebTrader (web-based) or AS2 B2B (server-to-server) and transmit directly. This is the path most pharma companies use.

Requires: - ESG account - Test transmissions in pre-production - Certificate management - ACK file processing

Option B: Safety Reporting Portal (SRP)

A web-based interface where you can either upload an E2B(R3) XML file or fill in a web form that the portal converts to E2B(R3) for you. Easier setup; lower volume capacity. Suited for small biotechs filing a handful of cases a year.

Hybrid: through a CRO or PV vendor

Many small biotechs delegate the actual transmission to a CRO or pharmacovigilance services vendor who has the ESG infrastructure set up. The biotech provides case data; the vendor generates and submits the XML.

A practical checklist for getting ready by October 1, 2026

If you haven't started yet, here's the realistic minimum path:

Get the official documents. Download the FDA Regional Implementation Guide (August 2024), the Core and Regional Business Rules (v1.6, January 2024), the Forward Compatible Rules, and the ICSR XML Instances examples. Read all of them.
Inventory your current state. Where do your ICSRs come from today? What's your current emission path? Are you on R2 currently, or filing on paper, or not filing electronically at all?
Pick your strategy. Building, buying, or contracting. The October deadline is not optional; the choice is just which path.
Set up an ESG account if you don't have one. This alone takes weeks. Don't leave it for September.
Validate against LSMV early. Even hand-written test XML can be uploaded to check rules. Don't wait until you have production cases to learn what FAERS rejects.
Plan your test → production cutover. Pre-production submissions don't count toward your no-reversion commitment, so use that environment until you're confident.
Document everything. What sender ID you use, which OID, which receiver, what your XML emission code does for each nullFlavor decision. This becomes critical when someone (an inspector, a new hire, your future self) has to debug a rejection two years from now.

Where to go from here

If you're at the "I need to start" stage:

Read How to Fill Out FDA Form 3500A — the underlying data model is shared; understanding the form makes understanding the XML easier.
Download the FDA Regional Implementation Guide.
Set up a sandbox ESG account.

If you're at the "I have a draft pipeline and it's failing validation" stage:

Run your XML through FDA's LSMV validator.
Cross-check rejection codes against the Core and Regional Business Rules document.
For nullFlavor rejections specifically, check the per-element permitted list rather than assuming a global default works.

If you're at the "production submissions are getting rejected and I need to fix it now" stage:

Pull the ACK3 response. The specific FDA-VR-* error code maps to a rule in the business rules document.
Compare your XML to the FDA-published ICSR XML Instances examples — these are gold-reference cases.
If the rule looks ambiguous, check the ICH E2B(R3) Q&A document. It supersedes the IG where the two disagree.

Further reading:

FDA AEMS Electronic Submissions — the official starting point
FDA Regional Implementation Guide for E2B(R3) (August 2024)
ICH E2B(R3) Implementation Working Group — the Q&A document
FDA's LSMV Validator — free, official, sometimes flaky

If you found this useful, our companion piece on filling out FDA Form 3500A covers the underlying data model from the form-filling angle. The two articles together cover the full path from case data to FDA acceptance.