Structured Product Labeling (SPL) Essentials for Regulatory Affairs

When people talk about Structured Product Labeling (SPL), the conversation often sounds highly technical: XML, schemas, code lists, GUIDs. For regulatory affairs teams, however, the objective is much simpler. You want your label to be accepted by the US FDA, on time, without technical rejections or repeated follow-up.

Consider a common situation. You are part of a small regulatory team preparing a label update. The content has been carefully reviewed, the SPL is generated, and the submission is sent to the US FDA. Shortly afterward, a technical rejection arrives. The label text itself is correct, but a structural element in the SPL is missing or incorrect. Instead of moving on, you now spend days trying to understand what went wrong at a technical level. 

This blog is written for teams in exactly that position. It focuses on what truly matters in an SPL submission to FDA CDER, where issues most often originate, and how regulatory teams can establish a simple and reliable process without becoming XML specialists. The perspective throughout is practical: understanding just enough about SPL to stay in control, while allowing tools and systems to handle the technical complexity.

What SPL is doing in the background

SPL is the format the US FDA uses to receive and process drug labeling information. It is XML-based, but you can see it as a structured container for three main things: 

• Who and what: basic metadata about the product and the company 

• What the label says: the actual text of the prescribing information or Drug Facts 

• How the product is defined: ingredients, strengths, dosage form, route, packaging, etc. 

• Recognize each section of the label correctly 

• Link product data (like NDCs and UNIIs) to internal databases 

• Track label versions over time 

• You still focus on label content, as always 

• But you also need to make sure the structure and data around it are correct 

The good news: you do not have to write XML code. Modern SPL tools (including EXTEDO’s publishing solutions) let you work with forms and templates, and generate the XML in the background. Still, it helps to understand the basic logic. 

The core elements of an SPL submission 

Every SPL submission rests on three fundamental elements: document identity, labeling content, and structured product data.

The document identity tells the US FDA how a particular SPL fits into the overall labeling history of a product. Each submission includes a setID that remains constant across all versions, a document ID that is unique to the specific file being submitted, a version number that increases with each update, and an effective date. When a label is updated, the setID stays the same while the document ID and version number change. If these elements are not handled correctly, the US FDA may not recognize the submission as an update, which can trigger warnings or rejections.

The labeling content is the text most regulatory professionals are already familiar with. For prescription products regulated by CDER, the label must follow the structured labeling requirements, with defined sections such as Indications and Usage, Dosage and Administration, Contraindications, Warnings and Precautions, and Adverse Reactions. In SPL, these sections are not just headings; they are explicitly tagged so FDA systems can identify them. Missing sections or sections that are present but empty remain among the most common SPL problems.

In addition, SPL also includes structured product data. This covers active and inactive ingredients with their UNIIs, strengths and units, dosage form, route of administration, packaging configurations, and marketing category. This information links the label to the US FDA's product and listing databases. Even minor inconsistencies between this data and other regulatory records can lead to technical issues, regardless of how accurate the label text may be.

Common sources of SPL errors

Most SPL problems are not about complex XML. They are about small details that are easy to miss when you are under time pressure. 

One frequent issue involves formatting. Label text is often drafted in Word and then copied into an SPL tool. Word introduces special characters, such as smart quotes or unusual bullet symbols, that may not translate cleanly into XML. These characters can cause validation failures or unexpected display issues. Using plain text when pasting content and reviewing validator warnings carefully can prevent many of these problems.

Another common issue is missing or incomplete sections. US FDA expects specific sections based on product type, and placeholders that are left empty can be just as problematic as sections that are entirely absent. Working with consistent templates and comparing new submissions against previously accepted SPLs helps reduce this risk.

Versioning and identification errors also occur more often than expected. In busy environments, teams sometimes reuse an older SPL file without updating the document ID or version number. As a result, the US FDA may treat the submission as a duplicate or fail to link it correctly to the labeling history. Clear internal rules and automated ID generation within publishing tools are effective safeguards.

Data mismatches represent another major source of problems. Incorrect NDCs, wrong UNIIs, or inappropriate codes for dosage form or route of administration can all trigger issues. These errors are best avoided by reusing data from a central, authoritative source rather than manually re-entering information for each submission.

Finally, when SPL includes images such as principal display panels, additional technical requirements apply. File formats, sizes, naming conventions, and XML references must all be correct. Previewing the SPL with images before submission is essential to ensure everything appears as intended.

Building a small but robust QA routine 

A good way to think about SPL is: content first, structure second, QA last. If you formalize the last step, you avoid many repeated errors. 

You can keep your QA routine simple and still effective. For example: 

• Technical check 
  Run the SPL through a validator (FDA-based or integrated in your publishing system). Do not just check for “no errors”; also look at warnings that might affect interpretation. 
  
  
• Structural check 
  Ask: Are all required sections present and filled? Are there any obvious gaps, such as missing warnings or incomplete Drug Facts? 
  
  
• Data check 
  Compare key fields with your internal sources: NDCs, strengths, dosage form, route, ingredients, and marketing category. Check the IDs and version numbers again.
  
  
• Readability check
  Preview the SPL as a human reader would see it. Does the text flow? Are headings, lists, and tables readable? Are images shown correctly?
  
  
• Submission check
  Before sending: Is the file name correct? Is the folder structure according to the US FDA expectations or your gateway requirements? Are your ESG credentials or submission path ready? 

If you document this routine once and follow it for each SPL submission, it becomes very fast. Many EXTEDO customers integrate such checks directly into their publishing workflow, so that validation and QA steps happen naturally during the authoring process, not only at the very end. 

Staying in control with small teams

In large organizations, SPL is often handled by specialized publishing teams. Smaller companies rarely have that option. The same regulatory professionals responsible for labeling strategy must also manage technical formats and submissions.

In this environment, a few principles make a significant difference. Manual XML editing should be avoided in favor of tools that abstract technical complexity. Product data should be centralized so that the same information is reused consistently across submissions. Internal standards for templates, file naming, and versioning reduce variability and confusion. Finally, targeted expert support or training early on can prevent recurring problems and save time in the long run.

With these practices in place, SPL gradually becomes less of a special project and more like any other regulatory activity: structured, repeatable, and predictable.

SPL exists to enable the US FDA to work with consistent and structured labeling data, not to complicate regulatory work. Once regulatory teams understand how document identities, label sections, and product data interact, and once they support this understanding with appropriate tools and a light but effective QA process, SPL becomes far less stressful.

For regulatory affairs teams, especially smaller ones, the goal is simple:

1. Keep ownership of the labeling content

2. Let systems take care of the technical format as much as possible

3. Use a light but reliable QA routine to catch issues before the US FDA does 

With this combination, SPL becomes manageable, and your submissions to the US FDA CDER are more likely to go through on the first try. That is good for your timelines, good for compliance – and good for everyone who depends on clear, accurate product information.