The Spanish version is the authoritative reference. View in Spanish
Panama: Document Reception (MS)
1. XML RECEPTION PROCESS
This process allows receiving different types of documents from customers and suppliers through the channels offered by Gosocket. Once received, both the issuer and the recipient will be able to view the documents in the Received tray in Inbox, along with their respective graphic representation and attachments.
Likewise, our system performs a series of automatic validations to ensure that the structure and integrity of the information strictly comply with the requirements of the tax authorities.
The following image describes, step by step, the document reception flow within the Inbox platform:
Panama reception process
1. Methods for sending the XML document in Gosocket:
The supplier has the possibility of sending the XML document to the Gosocket platform in three ways:
a. The supplier manually uploads the XML file using Gosocket's Upload option. The requirements and conditions for this process are detailed in the Manual upload. section
b. The supplier sends the XML document through Gosocket's exchange mailbox . The requirements and conditions for this process are detailed in the Exchange mailbox. section
c. The supplier uploads the XML document through the Reception API of Gosocket. The requirements and conditions for this process are detailed in the Reception API's. section
Note: When using any of the following document reception channels:
- Exchange mailbox
- Manual XML upload (Upload option)
- Reception API
The system will automatically run schema, signature validations and the corresponding validation with the Tax Authority (TA).
2. Document reception and validation in Gosocket
The Gosocket portal downloads and processes the XML. When it is a tax document, it enters a reception validation process.
3. Document schema validation
First, a schema validation is performed on the XML document to ensure it complies with the format established by the tax authority. Depending on the result of this validation, the process can lead to one of the following scenarios:
d. Failed: The document does not comply with the tax format, the document reception flow will be stopped due to the schema error, it will be registered in Gosocket with Schema Error status, and the interface will show the icon 
and the notes of the document will detail the reason for the rejection, as follows:
Schema error icon in inbox
Document detail Notes section - Schema Error
Detail of the XML processing for the schema error
e. Successful: If the XML schema validation is correct, the document will continue with the reception flow.
Document detail Notes section - Successful schema validation
Special configuration: The XML has a schema error, but if the configuration is activated, this option allows the reception flow to continue:
This feature can be enabled independently for each company. Its purpose is that, if a schema error is detected in the XML when the document is received in Gosocket, the specific error detail will be automatically recorded in the "Notes" section of the document.
Despite this finding, the document will continue with its normal flow toward the following reception validations, such as the verification of the signature and of the tax authority.
The document will remain in Inbox as follows:
- In Gosocket, the document will remain in Validated ET with schema error status and the orange icon
will be shown, as follows:
For more details on how to configure this feature, see the following section: XML Configuration Presents Schema Errors and Reception Flow Continues
4. Document electronic signature validation
Second, a document electronic signature validation is performed to ensure that the information has not been altered. This validation can produce one of the following results:
f. Failed: This means the document has been altered; the document reception flow will be stopped due to the signature error, so it will be registered in Gosocket with Signature Error status, the interface will show an icon 
and the notes in the preview will indicate the reason for the rejection, as follows:
Signature error icon in Inbox
Document detail Notes section - Signature Error
Detail of the XML processing for the signature error
g. Successful: If the XML electronic signature validation is correct, the document will continue with the reception flow.
Document detail Notes section - Successful signature validation
5. Inbox icons for the reception validation results
Finally, both the issuer and the recipient will be able to view the results of the XML document validations in Inbox, as follows:
| No. | Status | Icon in the inbox interface |
|---|---|---|
| h | Document has schema error | |
| i | Document has signature error | |
| j | Document was left Accepted by the Tax Authority |  |
7. Issuance of commercial acknowledgments
Once the document has been received and validated, the necessary commercial or mercantile acknowledgments can be issued at your discretion from the inbox platform, or otherwise they can be sent through the exchange mailbox. This is explained in more detail in the section Commercial Acknowledgments.
2. MANUAL DOCUMENT REPROCESSING
Additionally, a button was implemented in Inbox that allows manually reprocessing tax documents that have Signature Error or Schema Error status.
Note: This option only allows reprocessing documents that were sent through the exchange mailbox, the reception API, or the manual upload (upload).
This reprocessing option can be found in the following path, as applicable:
- Inbox/Received/Options/Actions/Reprocess document without validating schema.
- Inbox/Received/Options/Actions/Reprocess document without validating signature.
- Inbox/Received/Options/Actions/Reprocess document.
Accompanied by a selector that, as its name indicates, will allow independently selecting an Electronic Document or a set of them.
Next, a pop-up window will be displayed in which the user must confirm that they want to revalidate the previously selected documents.
Once the reprocessing has been generated, a banner will be shown at the top of the page indicating that the document(s) were sent for reprocessing:
and finally, for any of the three reprocessing types generated through this option, the notes section will indicate:
- Records the email of the user who performed the document reprocessing.
- Generates a note “Document processed without schema validation” or “Document processed without signature validation”
- The document continues the reception validation flow.
This button allows reprocessing the different validations of the reception process:
2.1. Reprocess document without validating schema:
Allows the document to go through the reception validations without taking the schema validation into account; however, when selecting the document and applying this reprocessing without validating schema, the system:
- Records the email of the user who performed the document reprocessing.
- Generates a note “Document processed without schema validation”.
- The document continues the reception validation flow.
2.2. Reprocess document without validating signature:
Allows the document to go through the reception validations without taking the signature validation into account; however, when selecting the document and applying this reprocessing without validating signature, the system:
- Records the email of the user who performed the document reprocessing.
- Generates a note “Document processed without signature validation”.
- The document continues the reception validation flow.
2.3. Reprocess document:
Allows reprocessing the document from scratch and performs the reception validations again without omitting any validation; however, when selecting the document and applying this reprocessing, the system:
- Records the email of the user who performed the document reprocessing.
- Performs the reception validations without omitting any of them.
3. XML SENDING METHODS
Currently, there are three methods for document reception into the system:
- Manual upload: Importing the XML file using the Upload option in Gosocket.
- Exchange mailbox: Automated inbound flow through the exchange mailbox.
- Reception API: Connection via API for integrated processing.
3.1. Manual XML upload through Upload in Gosocket
Gosocket has a tool within the Inbox platform that allows the supplier to directly upload the XML file of their documents.
- Access path: Main menu > Upload > Manual Upload.
From this section, the user can select the XML file from their device's file explorer or, if preferred, drag and drop it directly onto the interface.
Once the document is received, the solution automatically starts the processing and validation flow.
Once the XML file is received through the manual upload option, the following will be identified:
a. How many XML files were received in total, how many were processed successfully, and how many have errors.
b. By clicking the “Details” button, a popup will be displayed with the “Error Details” identifying the possible errors that the XML file uploaded manually through this option may contain; otherwise, if the document has no errors, a detail will be shown indicating that it was successfully uploaded to the Gosocket platform:
c. Finally, the document will be displayed in the Inbox received tray, with all validations performed.
3.1.1. Considerations for manual XML upload
- Up to 100 XML files can be uploaded in a single upload.
- Schema, signature, and Tax Authority validations will be performed.
- The tax documents stipulated by the Tax Authority must be sent in XML format.
The tax documents that can be received are:
- Internal Operation Invoice
- Import Invoice
- Export Invoice
- Credit Note referring to one or more electronic invoices
- Debit Note referring to one or more electronic invoices
- Generic Credit Note
- Generic Debit Note
- Free Trade Zone Invoice
- Reimbursement
3.2. Exchange mailbox
This is the process by which the supplier sends its XML files through an email mailbox. Each country has specific addresses assigned according to the work environment.
The mailboxes that must be used, according to the environment, are:
- Sandbox (Testing):
pa_ms_sbx@inbound.gosocket.com - Production:
pa@recepcionprd.gosocket.net
3.2.1. Considerations for the exchange mailbox
It is important to keep the following points in mind when sending documents, as this will prevent them from being rejected by the application.
a. The tax documents that can be sent through the exchange mailbox are:
- Internal Operation Invoice
- Import Invoice
- Export Invoice
- Credit Note referring to one or more electronic invoices
- Debit Note referring to one or more electronic invoices
- Generic Credit Note
- Generic Debit Note
- Free Trade Zone Invoice
- Reimbursement
b. The tax documents stipulated by the Tax Authority must be sent in XML format.
c. They can be sent individually or as multiple XML files in the same email.
d. Multiple XML files can be sent compressed in a file, and only the .zip extension will be allowed.
e. The XML or compressed (.zip) files must be attached to the email sent to the mailbox provided by Gosocket.
f. Attachments can be sent, such as the invoice PDF or other documents that may be required.
g. The maximum weight allowed in an email containing related XML and PDF files is 20MB.
h. The solution is able to process the graphic representation PDF, in case it is included, and attachments that arrive at the mailbox, where, once received, they are stored and linked to their respective document, allowing them to be downloaded from within Inbox.
The process works as follows:
- If an XML document arrives at the exchange mailbox along with an additional PDF file with the same name, for example: Factura12345.xml and Factura12345.pdf, it is understood that the .pdf file is the graphic representation of the DTE, so it is synchronized that way in Gosocket and will be available for viewing.
- If an XML document arrives at the mailbox with more than one attachment of any extension, they are associated as attachments.
Note: If there are PDF files with a different name than the XML, they will be considered attachments.
- For sending attachments, it is recommended to send each DTE with its attachments separately, since if more than one XML document arrives, only the graphic representation will be stored, provided that the PDF file has the same name as its corresponding XML; the rest of the attachments will not be processed since there is no way to know which document to associate them with.
- Attachments can also be associated after the XML has been sent; for example, if the XML is sent without attachments, another email with attachments (PDF, Excel, Word, etc.) can be sent afterward, and these will be associated with the previously sent document, provided that the second email also includes the XML.
3.3. Reception API's
For the document reception process, Gosocket offers two API's that allow sending XML to the Gosocket platform:
3.3.1. UploadZipDocument:
This API allows sending a request that includes one or several XML and PDF files to Gosocket, packaged together in a compressed file (.zip). Once received, the system processes the document, generates the corresponding record, and securely stores it on the platform.
a. Tracking Management
To perform detailed end-to-end tracking of the PDF processing, from the moment the PDF enters the platform through the exchange mailbox, until the supplier sends Gosocket the XML and the PDF, this entire process is assigned two unique identifiers called "externalId" and "batchId".
b. Upload and storage
The API manages the reception of the .zip file, which must contain the PDF and its respective XML in Gosocket's native format for its correct integration into the ecosystem.
This API allows the reception, processing, and storage of electronic documents on the Gosocket platform.
c. Post-storage processing actions
Once the document has been successfully stored in Inbox, it will allow performing the following actions:
- Reception validations (Automatic): Technical verification of compliance with standards, including:
o Schema validation.
o Integrity of the document's Electronic Signature.
o Validations with the corresponding Tax Authority: Indicates whether the document was accepted, rejected, or has validation errors reported by the regulatory entity following the tax validation.
- Receiver message (Automatic): Application of receiver message events according to the current regulations of the tax authority.
- Smart Supply validations (Configuration on demand): Application of logical rules and approval flows configured in the Smart Supply module.
- File Distribution (Configuration on demand): Once the document has been processed on the Gosocket platform, and based on the prior parameterization of the distribution rules, the system executes the automated transfer of the files to the configured technical destinations. This functionality allows integration with various environments, such as:
o Windows servers.
o File transfer protocols (SFTP / FTP).
o Automated sending by email.
You can find the configuration details of the Reception API at the following link: API Reception.zip - Generic
3.3.2. SendDocumentToUpload:
This API allows sending a request that includes a single XML to Gosocket. Once received, the system processes the document, generates the corresponding record, and securely stores it on the platform.
a. Upload and storage
The API manages the reception of the file in XML format for its integration into the Gosocket ecosystem:
- Ingestion: Loads the document directly into Gosocket's Inbox module through the endpoint: POST - SendDocumentToUpload
- Persistence: Ensures the storage of the XML file on the platform's servers for its subsequent management.
b. Tracking Management
The successful execution of the API generates a unique identifier called trackId. This value is returned in the response and is essential for:
- Performing detailed tracking of the processing status.
- Checking the result of the upload through the endpoint: GET- GetDocumentUploadStatus
c. Post-storage processing actions
Once the document has been successfully stored in Inbox, it will allow performing the following actions:
- Reception validations (Automatic): Technical verification of compliance with standards, including:
o Schema validation.
o Integrity of the document's Electronic Signature.
o Validations with the corresponding Tax Authority: Indicates whether the document was accepted, rejected, or has validation errors reported by the regulatory entity following the tax validation.
- Receiver message (Automatic): Application of receiver message events according to the current regulations of the tax authority.
- Smart Supply validations (Configuration on demand): Application of logical rules and approval flows configured in the Smart Supply module.
- File Distribution (Configuration on demand): Once the document has been processed on the Gosocket platform, and based on the prior parameterization of the distribution rules, the system executes the automated transfer of the files to the configured technical destinations. This functionality allows integration with various environments, such as:
o Windows servers.
o File transfer protocols (SFTP / FTP).
o Automated sending by email.
You can find the configuration details of the Reception API at the following link: Reception API
4. COMMERCIAL ACKNOWLEDGMENTS
The commercial acknowledgment is intended to validate tax documents with the Tax Authority and, as a result, we will have a status change within our received documents tray in Gosocket's Inbox.
Through the use of these events, the recipient reports the reception, acceptance, or rejection of each document.
These events can be generated from two different points in Inbox, which we will explore below.
Currently, in Panama there is the sending of the commercial acknowledgment, called Receiver's Manifestation, which is generated for received documents and is intended to inform the Tax Authority of the following:
a. Confirmation of the operation details.
b. Confirmation of the operation.
c. Confirmation of the transaction.
d. Cancellation of the business transaction.
e. Non-recognition of the operation.
Once the documents have been received in inbox and have passed the reception validations, Gosocket allows applying the commercial acknowledgments as follows:
3.1. Receive the commercial acknowledgments through the exchange mailbox
3.2. Manually issue the commercial acknowledgment for these documents.
4.1. Receiving commercial acknowledgments through the exchange mailbox
To receive commercial acknowledgments through the exchange mailbox, the file must strictly comply with the specific structure required by the TA and have XML format.
<ApplicationResponse
xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
xmlns:sts="dian:gov:co:facturaelectronica:Structures-2-1"
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<ext:UBLExtensions>
...
</ext:UBLExtensions>
<cbc:UBLVersionID>UBL 2.1</cbc:UBLVersionID>
<cbc:CustomizationID>1</cbc:CustomizationID>
<cbc:ProfileID>DIAN 2.1: ApplicationResponse de la Factura Electrónica de Venta</cbc:ProfileID>
<cbc:ProfileExecutionID>1</cbc:ProfileExecutionID>
<cbc:ID>0000000000000000000</cbc:ID>
<cbc:UUID schemeID="1" schemeName="CUDE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:IssueDate>2026-06-30</cbc:IssueDate>
<cbc:IssueTime>15:14:00-05:00</cbc:IssueTime>
<cbc:Note>OK</cbc:Note>
<cac:SenderParty>
...
</cac:SenderParty>
<cac:ReceiverParty>
...
</cac:ReceiverParty>
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>030</cbc:ResponseCode>
<cbc:Description>Acuse de recibo de Factura Electrónica de Venta</cbc:Description>
</cac:Response>
<cac:DocumentReference>
<cbc:ID>FV0000</cbc:ID>
<cbc:UUID schemeName="CUFE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:DocumentTypeCode>01</cbc:DocumentTypeCode>
</cac:DocumentReference>
<cac:IssuerParty>
<cac:Person>
...
</cac:Person>
</cac:IssuerParty>
</cac:DocumentResponse>
</ApplicationResponse>
<ApplicationResponse
xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
xmlns:sts="dian:gov:co:facturaelectronica:Structures-2-1"
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<ext:UBLExtensions>
...
</ext:UBLExtensions>
<cbc:UBLVersionID>UBL 2.1</cbc:UBLVersionID>
<cbc:CustomizationID>1</cbc:CustomizationID>
<cbc:ProfileID>DIAN 2.1: ApplicationResponse de la Factura Electrónica de Venta</cbc:ProfileID>
<cbc:ProfileExecutionID>1</cbc:ProfileExecutionID>
<cbc:ID>0000000000000000000</cbc:ID>
<cbc:UUID schemeID="1" schemeName="CUDE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:IssueDate>2026-06-30</cbc:IssueDate>
<cbc:IssueTime>15:14:00-05:00</cbc:IssueTime>
<cbc:Note>OK</cbc:Note>
<cac:SenderParty>
...
</cac:SenderParty>
<cac:ReceiverParty>
...
</cac:ReceiverParty>
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>032</cbc:ResponseCode>
<cbc:Description>Recibo del bien y/o prestación del servicio</cbc:Description>
</cac:Response>
<cac:DocumentReference>
<cbc:ID>FV0000</cbc:ID>
<cbc:UUID schemeName="CUFE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:DocumentTypeCode>01</cbc:DocumentTypeCode>
</cac:DocumentReference>
<cac:IssuerParty>
<cac:Person>
...
</cac:Person>
</cac:IssuerParty>
</cac:DocumentResponse>
</ApplicationResponse>
<ApplicationResponse
xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
xmlns:sts="dian:gov:co:facturaelectronica:Structures-2-1"
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<ext:UBLExtensions>
...
</ext:UBLExtensions>
<cbc:UBLVersionID>UBL 2.1</cbc:UBLVersionID>
<cbc:CustomizationID>1</cbc:CustomizationID>
<cbc:ProfileID>DIAN 2.1: ApplicationResponse de la Factura Electrónica de Venta</cbc:ProfileID>
<cbc:ProfileExecutionID>1</cbc:ProfileExecutionID>
<cbc:ID>0000000000000000000</cbc:ID>
<cbc:UUID schemeID="1" schemeName="CUDE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:IssueDate>2026-06-30</cbc:IssueDate>
<cbc:IssueTime>15:14:00-05:00</cbc:IssueTime>
<cbc:Note>OK</cbc:Note>
<cac:SenderParty>
...
</cac:SenderParty>
<cac:ReceiverParty>
<cac:PartyTaxScheme>
...
</cac:PartyTaxScheme>
<cac:Contact>
...
</cac:Contact>
</cac:ReceiverParty>
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>033</cbc:ResponseCode>
<cbc:Description>Aceptación expresa</cbc:Description>
</cac:Response>
<cac:DocumentReference>
...
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>
This XML file, which contains the structure of the commercial acknowledgment, must be sent once the invoice is already registered in Inbox, sending it to the same reception mailbox.
Once the acknowledgment enters through this channel, it can be viewed as an attachment within the Attachments section in the document preview, as follows:
4.2. Manually issue the commercial acknowledgment for these documents.
These events can also be generated from the Inbox document preview, which we will explore below.
4.2.1. Applying commercial acknowledgments from the document preview
This action can be performed from the document preview through the Receiver's Manifestation button.
When entering any of the Acknowledgments, a pop-up window will be displayed with a form to leave a comment.
This event will be displayed within the document preview in the notes section, and the XML of the event sent to the Tax Authority will be shown:
and in the attachments section, as shown below:
5. QUERYING DOCUMENTS RECEIVED FROM GOSOCKET
Once the documents have been processed by the reception service, they can be queried from the Gosocket portal in the Inbox/Received section. **
This section displays the following screen:
**1.**Filters section to optimize the search results. **
**2.**Display order control, with which you can modify how the search results are presented. **
**3.**List of options related to export, commercial responses, and internal movements of the Electronic Documents. **
**4.**Display section with the details of the search results and icons representing the most relevant status changes. **
* For more information about these points, see the Inbox documentation.**
Once the document search has been performed in the main grid, the list of received documents that met the established search criteria will be displayed; in this grid, in addition to relevant document information, the document status can also be observed.
**1.**Validation with the tax authority.
**2.**Distribution validation.
**3.**Smart Supply status validation.
In the status column (1), the result of the applied validations will be shown, as explained in the section XML Reception Process
| Icon | Status | Validation |
|---|---|---|
 | VALIDATED | Document approved by the TA |
| * | Signature Error | Document with signature error |
| * | Schema Error | Document with schema error |
| ** | Schema error but flow continues * | The XML has a schema error, but if the configuration is activated, this option allows the reception flow to continue. |
* Note: By clicking on the document, the document preview will open, where you can review the notes related to the reason for schema rejection or signature rejection.
* Note: Special configuration: The XML has a schema error, but if the configuration is activated, this option allows the reception flow to continue:
This feature can be enabled independently for each company. Its purpose is that, if a schema error is detected in the XML when the document is received in Gosocket, the specific error detail will be automatically recorded in the "Notes" section of the document.
Despite this finding, the document will continue with its normal flow toward the following reception validations, such as the verification of the signature and of the tax authority.
The document will remain in Inbox as follows:
In Gosocket, the document will remain in Validated ET with schema error status and the orange icon will be shown, as follows:
For more details on how to configure this feature, see the following section: XML Configuration Presents Schema Errors and Reception Flow Continues