I am missing a file from a seller. Where can I locate it?

As a general rule, files flow as follows:

1. Files originate in the seller/ship-to EPCIS system and are forwarded using an AS2 system
2. The sender’s AS2 and Gateway Checker’s AS2 platform transfer the file using an encrypted link
3. The file is transferred from Gateway Checker’s AS2 platform to its EPCIS platform
4. The file is downloaded by the ERP system

If an inbound EPCIS file does not appear as expected in the ERP application, follow the steps below to help locate it.

1. Check the Gateway Checker Portal

• Log into the Gateway Checker production system.
• Go to the Receive tab.
• Use the search box and Filter button with one or more of the following:
• Purchase order number
• File name
• Seller’s GS1 Company Prefix (GCP) (the seller not the ship-from)

💡Tip: If unsure whether you are seeing the correct file, use the Drug Transaction Summary Report to view the shipment contents.

2. Confirm File Status

Files that have errors may not be visible.

• The file should have a status of “Arrived” — indicating the file has arrived successfully.
• Check the TraceReady report for FAILs
• Check the Drug Transaction Summary Report. If that exists, then the file has been successfully loaded into the Gateway Checker database.
• If everything is working, each new file is assigned a Transaction ID (TID) and downloaded by the ERP system within a few minutes. Blue Link ERP downloads typically occur every 10 minutes (or so).

3. Places that Gateway Checker Admins Can Check

• Files are first received through the Gateway Checker AS2 system.
• Gateway Checker Admin Support can search the AS2 inbox using:
• AS2 Message ID
• Date-time stamp
• File name
• Sender

We receive a large volume of files, so locating one can feel like searching for a needle in a haystack. If the seller provides AS2 transfer information (Message Disposition Notice (MDN) or Transport Headers), it gives us the info above.

• Inbound files with an incorrect seller or buyer SGLN are placed in the AS2 reject queue.
• Gateway Checker support reviews this queue daily and resolves issues such as:
• Linking an unrecognized buyer/seller trade partner
• Informing the parties involved that an SGLN must be corrected

Once resolved, the file is reprocessed (if possible) and resumes normal flow.
 

To better support your understanding, the process of sending an outbound file occurs as follows:

1. The First Steps:

Files originate in your ERP application, such as: 

• Blue Link ERP
• Other ERP systems
• Other applications calling Gateway Checker MedTracker

2. EPCIS File Creation

When your ERP system (or other application) completes all required steps, it:

• Makes a call to the Gateway Checker system
• Requests creation of an EPCIS file
• The newly created EPCIS file is posted to the Gateway Checker portal

3. Verifying File Transmission 

Step 1: Check the Gateway Checker Portal

1. Log in to the Gateway Checker portal

2. Click on the “Send” tab

3. Review your sent files list

Step 2: Examine File Details

For each file, you’ll see:

• Transaction ID – Unique identifier for the transaction
• File Name – Name of the sent file
• Purchase Order Number – If applicable
• Buyer – Company name (if the buyer is registered in the Gateway Checker trade partner table)
• Status – Transmission status indicator

Step 3: Interpret Status Indicators 

Shipped (Green)

• File Description: Target AS2 ID
• Meaning: Successfully shipped via AS2
• Action Required: MDN and transport headers are available upon request.

Shipped (Black / Plain Text) – TraceLink

• File Description: Target TraceLink AS2 ID
• Meaning: Successfully shipped via AS2
• Action Required: MDN and transport headers are available upon request. 

Shipped (Black / Plain Text) – EPCIS Available

• File Description: EPCIS Available (4)
• Meaning: EPCIS file has been created
• Action Required: Download the EPCIS file and forward it to the trade partner. 

Shipped (Yellow) 

• File Description: Error Message
• Meaning: Not forwarded due to missing AS2 information
• Action Required: Trade partner lacks configuration information. 

Shipped (Red) 

• File Description: Error Message
• Meaning: Usually indicates an AS2 transmission error
• Action Required: Contact Gateway Checker. 

Troubleshooting Steps

If Status Shows Successful Transmission (Green/Black)

1. Note the Transaction ID from the portal 
2. Contact your Gateway Checker administrator with the Transaction ID 
3. The administrator will: 

• Locate the associated file name 
• Check the AS2 platform for transmission details 
• Review status indicators for successful delivery or issues 

If Delivery Was Successful

The administrator can download proof of receipt:

• Transport Headers – Original message headers 
• MDN (Message Disposition Notification) – Official receipt confirming the receiving system accepted the file 

With this proof, the receiving party can search for the file in their system.

If Status Shows Not Forwarded (Yellow/Red)

• Yellow Status: Contact support to add AS2 configuration for the trade partner
• Red Status: Contact support to investigate the technical issue
   

Support Contact

For assistance with transmission issues or AS2 configuration, contact your Gateway Checker administrator with: 

• Transaction ID
• Buyer name
• Date/time of transmission attempt 

The DSCSA, enacted in 2013, is a federal law designed to secure the U.S. prescription drug supply chain by enhancing product traceability, verification, and serialization.

It requires all authorized trading partners — manufacturers, repackagers, wholesale distributors, and dispensers — to:

• Exchange Transaction Information, Transaction Statements, and product identifiers.
• Use serialization to uniquely identify packages.
• Verify and handle suspect or illegitimate products.
• Implement interoperable electronic systems by the final compliance deadline.

More Information:

Drug Supply Chain Security Act

FDA Guidance on Trading Partners

Frequently Asked Questions (FAQs) by the Pharmaceutical Industry in Preparing for the U.S. DSCSA
  

EPCIS (Electronic Product Code Information Services) is a GS1 standard for sharing detailed, event-based data across the supply chain.

In DSCSA, EPCIS is the recommended format for trading partners to electronically exchange product data, such as:

• What product moved
• Where and when it moved
• Why it moved (e.g., shipped, received, sold)
• Who was involved

It helps ensure interoperability between systems and is a key tool for meeting DSCSA traceability and serialization requirements.

More Information:

GS1 US: EPCIS for DSCSA
 

Due to implementation challenges, the FDA granted temporary exemptions to some partners under the “stabilization period” (post-Nov 2023).

Exempt Partners & Timelines:

• Manufacturers / Repackagers – until May 27, 2025
• Wholesale Distributors – until August 27, 2025
• Dispensers (26+ staff) – until November 27, 2025
• Small Dispensers (≤25 staff) – until November 27, 2026

These partners are temporarily exempt from:

• Using interoperable electronic systems.
• Including package-level serialization in data exchange.
• Some verification requirements (e.g., for saleable returns).

More Information:

Waivers and Exemptions Beyond the Stabilization Period
 

You may be covered for that specific transaction, but only if:

1. The exemption applies to the exact DSCSA requirement relevant to your transaction.

2. You are an immediate trading partner of the exempt entity.

3. The exemption is clearly communicated and documented between you and your partner.

You are still responsible for maintaining DSCSA compliance in all other areas not covered by the exemption. This includes:

• Verifying product legitimacy
• Maintaining secure systems for traceability
• Continuing efforts toward EPCIS-based data exchange

More Information:

Exemptions from Certain Components of the DSCSA
 

Connecting a seller/vendor into the Gateway Checker system is a simple process.

First, you (the subscriber) must ensure you have located and stored your master data information. This includes the SGLN, GCP, GLN, and your corporate address. This information is required to send and receive EPCIS data with your vendors (and customers).

Next, the Gateway Checker onboarding team needs a list of suppliers, along with the same master data information as above and each of their serialization solution providers (TraceLink, LSPedia, rfxcel, etc.). Gateway Checker already has an active connection with most solution providers, making the process even simpler.

As you contact your suppliers, please CC the Gateway Checker group email address assigned to your organization so our entire onboarding team can support the configuration process. Once the connection is completed, Gateway Checker will request a test file from your supplier to ensure the files can be received correctly and are conformant to both DSCSA and EPCIS standards.

Once the test file is received and is confirmed to meet the requirements, we will move the connection to production. Once files arrive, subscribers can either access their files through the Gateway Checker portal, or the Blue Link portal (if you are affiliated with Blue Link ERP).

*Note: Gateway Checker does not provide logins for vendors or customers of subscribers*

Please contact the Support Team with any questions pertaining to onboarding: support@nullgatewaychecker.com
 

Gateway Checker can create logins for subscribers, as well as team members within their organization, to provide them access to the Gateway Checker portal. From here, users can navigate to their inbound and outbound environment and retrieve files directly through the Gateway Checker portal. Furthermore, they can see whether files met conformance standards, and if not, the specific areas of the DSCSA and/or EPCIS they did not meet.

If your organization is a Gateway Checker subscriber, contact support@nullgatewaychecker.com so a member of our team can add additional users to your Portal and QA (test) accounts.
 

The icons you are referring to are our TraceReady scoring symbols. Whenever an inbound file is received into the Gateway Checker system, that file is automatically evaluated against Gateway Checker’s TraceReady scoring framework. TraceReady’s framework was developed against 7 different EPCIS and DSCSA metrics, preventing nonconforming files from infecting the supply chain.

• A Green checkmark indicates a Pass — no issues in the file
• A Yellow checkmark indicates a “Pass with Warnings” – minor findings that should not affect file ingestion (example, bizLoc SGLN extension is not zero; product drugID NOT is an 11-digit NDC)
• A Triangle with an exclamation mark indicates a “Pass with Alerts” – findings that probably won’t affect file ingestion, may be a problem depending on policies of the subscriber (example, missing purchase order, which you can check for)
• A Red X indicates a Fail – major findings that will likely affect file ingestion, sender should fix (example, malformed SGLN/SGTIN). Files that fail should not be accepted by your ERP provider, and therefore, you need to contact the supplier to address these issues. Gateway Checker will send out Critical File Failure Reports when files fail against the TraceReady assessment – see the next question for more information on Critical File Failure Reports. 

Critical File Failure Reports is an initiative Gateway Checker implemented for subscribers in June of 2025. The Critical File Failure Reports leverage Gateway Checker’s TraceReady Assessment, pinpointing areas of EPCIS and DSCSA nonconformance for your inbound files and describing the reasons for these failures. These failures could prevent your ERP system from accepting the EPCIS files.

Each day, the Gateway Checker support team evaluates all inbound files, looking for ones which failed our TraceReady quality assessment; when a file fails, the Gateway Checker service team generates the Critical File Failure Report for the file, then sends it over to the specific subscriber who received the file.

When a subscriber receives one of these files, we highly recommend reaching out to the supplier who produced the nonconforming file and have them address the issues associated with it. The Gateway Checker service team is happy to help provide support to suppliers who may need additional help creating a conformant file, so please feel free to include the Gateway Checker team in this email correspondence, using your team’s Gateway Checker email address.

If an inbound file does not show a TraceReady score (and appears blank), please select the file and click the “Generate Reports” button.

If a score does not generate for the file, please contact the Gateway Checker team (support@nullgatewaychecker.com)

Gateway Checker does not send the outbound files ourselves. We ensure the AS2 connection is made between our server and the buyer/customer by exchanging AS2 certificates (we are connected with most AS2 providers already). Additionally, we configure their master data into the Gateway Checker system to ensure the proper delivery of data once outbound files are sent out.

However, when it comes to generating outbound files, this occurs external to the Gateway Checker environment (through your ERP provider like Blue Link). If the master data and AS2 connection have been correctly established in Gateway Checker, the file status will show as “shipped” with a green checkmark, and the Description will depict the AS2 connection to which the file was successfully sent.
 

AS2 is very commonly used as a secure protocol for sending and receiving test and production files between trade partners. AS2 is widely used because it meets strict security, compliance, and reliability standards, providing trade partners with the confidence that their files will be delivered both directly to the trade partner and in a secure manner. AS2 uses encryption and digital signatures to protect this sensitive data as it moves from one trade partner to another.

In order to establish an AS2 connection, Gateway Checker needs to send our AS2 information and certificates, and the customer needs to provide their AS2 information as well (for example, LSPedia, Infinitrak, TraceLink). Gateway Checker is connected with most AS2 providers already, making this process very simple.
 

Different statuses mean different things, and are important to recognize to better understand how your customers can access their files.

A green checkmark with the “shipped” text indicates the file was successfully sent via AS2 or email (as configured in the Gateway Checker system), and that the master data for that customer was configured in the Gateway Checker system. The file will only be sent via email if there is no AS2 information configured in the trade partner entity—if a file has been shipped to an email and you would like it to be sent via AS2, please contact a member of the Gateway Checker team and we will work to configure the connection via AS2.

A yellow checkmark with the “shipped” text indicates that the SGLN was not configured into the Gateway Checker system; however, the EPCIS file was still created, and can be accessed through your ERP provider (for example, Blue Link ERP).

When there is no checkmark and “shipped” text, the file has been shipped to the TraceLink AS2 or Advasur AS2 endpoint.

A red “X” indicates the file did not get sent to the provided email address or AS2 address, the file was unable to be generated, and therefore it will not be sent to the appropriate customer. Please contact the Gateway Checker team if a file depicts a red “X” in the outbound portal to ensure your files are generated and shipped properly over AS2.

Support email: support@nullgatewaychecker.com
 

The below is from Blue Link:

Sending a test file to a customer is just creating a sales order for them in the WebTest / Playground database, but scanning a “real” serial number on the way out.

The Blue Link WebTest database is connected to the GatewayChecker QA system which generates those test files.

The pre-requisites for sending the files are:

1. The customer in question who wants the test file — you need their GLN / GS1 Company prefix loaded into Blue Link at the Bill to and Ship to level; and you have to check the EPCIS Enabled checkbox.
2. Gateway Checker has to have an AS2 connection established in the QA environment for their GLN (so that it can actually send the test file).
3. You create a test sales order, containing an EPCISEnabled = True inventory item for which you have stock, allocate a lot for which you have stock, and then scan the serial of that item (you obviously do not actually ship the product in the real world, but you need the scan of a real item to get a valid GTIN/Serial to be included in the file.
4. You post the invoice — which generates the outbound queue request and creates the shipment in the Gateway Checker QA System.

Gateway then transmits that file to the customer (assuming that step 2 was done).

If the customer doesn’t receive the test file, check the Gateway Checker portal “Send” tab. If the file has a status of”Shipped” then Gateway Checker can provide an MDN/Transport header, which is proof of delivery.
 

The Gateway Checker system uses the buyer SGLN (destination owner) as a routing key to determine where to forward EPCIS files. If the SGLN in your file doesn’t exactly match what’s configured in our routing table, the file will fail to forward. A typical error in this case is yellow status and “SGLN not found” in the Description field on the Gateway Checker portal.

Example scenario:

• Your EPCIS file used SGLN 120014484991..0 as the destination owner (buyer)
• Our routing table was configured with SGLN 120014494409..0 for the same company
• Even though both SGLNs could represent the same physical address, the Gateway system couldn’t match on the SGLN
• Result: File created successfully but couldn’t be forwarded to the trading partner

Best practice: We recommend using the corporate/legal entity SGLN as the buyer rather than individual location SGLNs. This approach allows us to:

• Cover multiple ship-to locations with a single routing table entry
• Reduce configuration complexity
• Avoid routing failures

Key takeaway: The Gateway system requires an exact SGLN match between your EPCIS file and our routing configuration. Please coordinate with us on which buyer SGLN you plan to use so we can ensure proper routing table setup before you begin sending files.
 

Gateway Certified is a program offering pharmaceutical trade partners the industry’s “seal of approval”, demonstrating commitment to and alliance with FDA DSCSA compliance standards. Leveraging Gateway Checker’s TraceReady application for drug transaction quality assurance, outbound files are tested under rigorous DSCSA standards.

Depending on the makeup and contents of the file, outbound files can be tested under one (or a few) of 16 different traceability scenarios. Each traceability scenario represents a use case of predefined operational considerations, such as supply chain role, aggregated or non-aggregated, number of purchase orders in the shipment, direct purchase, and shipments sent direct to the buyer or drop shipped.

Once an outbound file is generated and passes one (or multiple) of these traceability scenarios, then that file will become Gateway Certified. Upon successfully generating the outbound file, your organization will be presented with the Gateway Certified seal, which can be used in your own marketing materials (in accordance with our branding guidelines) to demonstrate commitment to DSCSA compliance.

Gateway Checker is certified by the GS1 US RX EPCIS Testing Service Certification Program — the only conformance testing service with this accreditation available today.

For more information about the Gateway Certification Program, contact our marketing team:

marketing@nullgatewaychecker.com
 

Gateway Certification is available for manufacturers, distributors, wholesalers, as well as solution providers. We can certify outbound files under 16 different traceability scenarios, depending on the trade partner and the type of file (for example, Single Purchase Order without Aggregation).

Users can elect to automatically apply for a GS1 US Trustmark upon the successful attainment of a Gateway Certificate.

Contact marketing@gatewaychecker.com if you’re interested in becoming Gateway Certified.  

You can access the Critical Failure Report on a self-service basis. Login to the Gateway portal. Click on the file name. Click on the “Critical Failure Report” tab (takes a few seconds).

Enter the target email addresses separated by semicolons. Hit Send, or click the download button if you’d prefer to send the file via email directly.

However, please note that the Gateway Checker team sends out these Critical File Failure Reports directly to subscribers each business day. The above is just in case you’d like to send out these reports yourself, and/or store them for your own internal purposes.

The golden rule of DSCSA compliance: Your digital records must accurately reflect what happens to the physical product.

When pharmaceutical products experience exceptions (damage, returns, quarantine, etc.), proper handling requires both physical management and corresponding digital record updates.

Gateway Checker Item Condition Management and Available Item Conditions:

Gateway Checker stores an itemcondition for each itemID (SGTIN/SSCC) with the following status options:

• Active – Product is available for normal distribution
• Inactive – Product removed from circulation
• Destroyed – Product has been destroyed and cannot be redistributed
• Returned – Product returned to seller
• Quarantined – Product held pending investigation or resolution

We cannot provide specific guidance on Blue Link UI (or other application) capabilities for setting item conditions, as we don’t have visibility into their interface. Contact Blue Link support (or your application support) to understand available item condition management features.
 

Many trade partners have been assigned a single-use Global Location Number (GLN) by GS1 or one of the major wholesalers.

For example:1200144531937

This GLN enables the entity to create a single SGLN: 120014453193..0 which can be used as a source/destination address in a drug transaction.

Companies are then tempted to use the 12-digits of the GLN in place of a GS1 Company Prefix (GCP) to create GS1 identifiers (SSCCs, SGTINs), like this:

urn:epc:id:sscc:120014453193.06998

This is NOT allowed by GS1.

For definitive guidance, please refer to the EPC Tag Data Standard (TDS), Release 2.2, Ratified, Feb 2025, section 7.2

In such cases, a subscribing organisation SHALL NOT use the digits comprising a particular individually assigned key to construct any other kind of GS1 key. For example, if a subscribing organisation is issued an individually assigned GLN, it SHALL NOT create SSCCs using the 12 digits of the individually assigned GLN as though it were a 12-digit GS1 Company Prefix.

In order to create GS1 identifiers, trading partners must purchase a GS1 company prefix.
 

Yes, Gateway Checker can also handle drop shipments. In a drop shipment, a seller sends a file to a buyer who is not a Gateway Checker subscriber.

The EPCIS file also includes a “destination location” (the ship-to SGLN). When Gateway Checker receives the file, it first checks the buyer SGLN. If the buyer is not recognized as a subscriber, it then checks the destination location. If the destination location is a Gateway Checker subscriber, the routing algorithm evaluates the file as a potential drop ship. The system verifies that the destination owner is a linked, onboarded trading partner of the subscriber. If that check passes, the file is delivered to the destination location, which is the subscriber in this transaction.

There is also a scenario where two Gateway Checker subscribers have a close business relationship. If a file comes in with the destination owner as Subscriber A and the destination location as Subscriber B, the file is delivered to Subscriber A. If the seller wants the file delivered to Subscriber B instead, then Subscriber B must be listed as the buyer.
 

Gateway Checker primarily uses the buyer’s SGLN (also known in EPCIS as the destination owner) to route files to subscribers. When the buyer’s SGLN matches a subscriber, the file is delivered to that subscriber. This is the standard routing case and applies to the majority of files.

There is also a scenario where two Gateway Checker subscribers have a close business relationship. If a file comes in with the destination owner as Subscriber A and the destination location as Subscriber B, the file is delivered to Subscriber A. If the seller wants the file delivered to Subscriber B instead, then Subscriber B must be listed as the buyer.
 

When a requester produces a product verification request, a response will be provided which determines the validity of the request. Different response codes mean different things, and require different resolutions/courses of action.

The below section highlights the different responses and suggested resolutions when a requester receives them. Also noted in each of the below sections are the frequencies of occurrence for each of these requests, based on over 60,000 product verification requests during September 2025.

✅ Successfully Prepared Request

• 200 – The request was successful
• Resolution: None
• Frequency: 74%
• 404 – Not Found
• GTIN may be missing in Lookup Directory/Resolver or has an expired GTIN record.
• Resolution:
• Check GTIN matches the product and resubmit if errors found.
• Contact manufacturer to confirm GTIN exists.
• Contact Verification Service Provider to ensure lookup directory is synchronized.
• Frequency: 24%

❌ Unsuccessful Verification Request

• 400 – Bad Request
• The request was not formatted properly.
• Resolution:
• Check that the request conforms to the specification and re-issue in correct format.
• Frequency: 0.9%
• 401 – Unauthorized
• Request did not pass authentication.
• Resolution:
• Check and obtain necessary authentication credentials.
• Frequency: 0.0%
• 403 – Forbidden
• Request was valid, but server refused due to lack of permission or expired/invalid ATP Verifiable Credential.
• Resolution:
• Check and obtain necessary permissions and credentials.
• If ATP Verifiable Credential is provided in header, resolve credential issue and resubmit.
• Frequency: 0.0%
• 405 – Method Not Allowed
• Request method is not supported.
• Resolution:
• Check and correct method names and parameters.
• Frequency: 0.0%

⚠️ Verification Network or System Failure

• 408 – Request Timeout
• Server timed out waiting for the request.
• Resolution:
• Retry sending request to server.
• If timeout continues, check connectivity and contact Verification Service Provider.
• Frequency: 0.0%
• 500 – Internal Server Error
• System failed to process request due to internal error.
• Resolution:
• Contact Verification Service Provider.
• Frequency: 0.5%
• 502 – Bad Gateway
• One server tried to use another VRS system and that system was down.
• Resolution:
• Retry sending request to server (limited by credential expiration).
• If timeout continues, check connectivity and contact Verification Service Provider.
• Frequency: 0.1%
• 503 – Service Unavailable
• System undergoing maintenance or temporarily unavailable for API queries.
• Resolution:
• Retry sending request to server (limited by credential expiration).
• If timeout continues, check connectivity and contact Verification Service Provider.
• Frequency: 0.0%
• 504 – Gateway Timeout
• Server performed multiple retries but did not receive timely response from upstream server.
• Resolution:
• Retry sending request to server (limited by credential expiration).
• If timeout continues, check connectivity and contact Verification Service Provider.
• Frequency: 0.1% 

A VRS System is the most effective means to verify product identifiers instantaneously, with the capacity to verify the printed barcode of a US pharmaceutical product in as quickly as one second. These systems have become widely adopted across the supply chain, particularly amidst the implementation of Enhanced Drug Distribution Security Requirements of the DSCSA.

When the requester (typically a wholesaler) generates a request to a manufacturer or repackager to verify the product identifier, the VRS system allows the manufacturer or repackager to respond with a clear indication of whether or not the product identifier can be verified; these responses should occur within one business day/24 hours (as per FDA Guidances). The responses to these requests include a variety of different codes (see “What do the different product verification response codes mean, and what is the appropriate resolution for each?” for what each of these codes specifically mean).

The process is as follows: once a Regulator or Authorized Trade Partner (typically wholesaler) submits a product verification request, the product identifier information within that 2D Data Matrix is compared with the GTIN Look-up directory service. Depending on the result, the responder produces the appropriate response back to the requester, and the requester acts accordingly (again, see “What do the different product verification response codes mean, and what is the appropriate resolution for each?”).
 

Yes, product verification is a requirement under the DSCSA, with various components of the legislation specifying necessary steps to validate potentially counterfeit, item-level packages.

As per the DSCSA:

• “Verify” or “Verification” means confirming with the manufacturer or repackager that the product identifier on the package is the one the manufacturer or repackager assigned.
• All trading partners must also have “verification systems” for the management of suspect and illegitimate products. Under the Enhanced Drug Distribution Security requirements (which went into effect on May 27, 2025 for Manufacturers and Repackagers, on August 27, 2025 for Wholesale Distributors, and will be implemented on November 27, 2025 for Large Dispensers (more than 25 full-time employees)), item-level product verification is a requirement.

When it comes to responding to product verification requests, the FDA has emphasized the importance of timely responses. The DSCSA recommends the following in one of their recent guidances pertaining to product verification requirements, titled Enhanced Drug Distribution Security Requirements Under Section 582(g)(1) of the Federal Food, Drug, and Cosmetic Act:

• Manufacturer or repackager should respond within 24 hours/1 business day to a verification request from an Authorized Trading Partner (ATP) in possession or control of the product.​