Skip to content

fiskaly SIGN PT

fiskaly SIGN PT is a cloud-based fiscalization solution for the Portuguese market, designed to support POS providers, integrators, and taxable persons in complying with Portuguese invoicing and fiscalization requirements, including Decree-Law No. 28/2019, Ministerial Order (Portaria) 363/2010 and No. 195/2020, and the Order (Despacho) No. 8632/2014. The service provides Portuguese-compliant invoicing functionalities such as signing/journaling, series management, ATCUD/QR code support, and SAF-T (PT) reporting. Where agreed, SIGN PT may be used together with fiskaly SAFE for archiving and retention. The service is accessed via a RESTful API and managed through the fiskaly HUB.

SIGN PT provides a structured framework designed to support compliance with Portuguese invoicing and fiscalization requirements, provided the Customer implements and uses the service strictly in accordance with fiskaly’s written documentation and any applicable approval conditions. Key aspects include:

  • Series Management & Identification: Creation, communication, and management of document series, including interaction with the AT (Autoridade Tributária) for obtaining validation codes / ATCUD.
  • Signing & Journaling: Digital signing functionalities supporting integrity, chronological sequencing, and traceability of fiscal documents.
  • SAF-T Reporting: Communication with the AT, including real-time reporting and generation of SAF-T (PT) files.
  • Archiving (optional via SAFE): Secure long-term storage, retention, and retrieval of fiscal data.
  • Series Management: Register new document series with the AT, manage their lifecycle (open/close), retrieve validation codes.
  • Document Fiscalisation: Processing of Simplified Invoices (FS), Invoice-Receipts (FR), Credit/Debit Notes (NC/ND). Standard Invoices (FT) and Transport Guides (GT, GR) will follow soon.
  • Cryptographic Signing: Digital signature generation with chaining (hash of previous document included in the current signature).
  • ATCUD and QR Code Support:
    • ATCUD: The service supports the generation and composition of the unique document code (ATCUD) required for relevant documents, subject to prior communication and validation of the corresponding series with the AT.
    • QR Code: The service supports the generation of the QR-related output required for fiscally relevant documents. The Customer remains responsible for ensuring that the final document output includes the QR code and all relevant elements in a legible manner and in accordance with the applicable specification.
  • Communication with AT:
    • Real-Time Reporting: Automatically submits invoices and transport documents to the AT via webservices (WSA/WDT).
    • SAF-T (PT) Generation: Generates the Standard Audit File for Tax (SAF-T PT) XML required for monthly reporting.
  • Data integrity: Chain of signatures/hashes for traceability; corrections via corrective or reversal documents.
  • Archiving (optional via SAFE): The optional fiskaly SAFE service ensures the secure storage of fiscal data and long-term retention, with full search and export capabilities for audit and compliance purposes.
  • A valid contractual relationship with fiskaly.
  • An internet connection, specifically for real-time communication with the AT.
  • Integration of the SIGN PT API per fiskaly documentation.
  • A compatible POS system capable of receiving, rendering, and printing (or generating in PDF) all mandatory output elements.
  • Valid AT credentials, permissions, sub-user access, and instructions for series communication and real-time reporting.
  • The Customer must ensure final documents include all mandatory visual elements (ATCUD, QR code, certification statement, hash characters) per fiskaly’s written specifications and applicable law.

fiskaly is committed to maintaining and updating SIGN PT. fiskaly undertakes to maintain and update the Service with a view to supporting its security, availability, and ongoing alignment with applicable AT technical and reporting requirements; however, the Customer remains responsible for implementing required updates, migrations, and integration changes on its side. The service is versioned according to semantic versioning; significant changes resulting in new major releases will be documented. Maintenance activities may result in the temporary outage of the service. As far as possible, these activities shall be announced at least two (2) weeks in advance; emergency maintenance activities may deviate from this. fiskaly provides assistance to customers via the fiskaly support portal (support.fiskaly.com).

fiskaly provides a TEST environment for SIGN PT and SAFE. The TEST environment is fully functional with the same properties as the LIVE system. Documents created in TEST are not legally valid and are not communicated to production AT servers. fiskaly is not responsible if real data is used in the TEST environment.

  • Semantic/tax validation: While SIGN PT may validate certain technical or schema-related elements (such as field presence, formatting, or structural consistency), it does not verify the substantive tax correctness, legal classification, or business accuracy of the data submitted. The Customer/Taxpayer remains responsible for the substantive correctness of the transaction data, including VAT treatment, exemption codes, tax region selection, and the lawful qualification of the underlying transaction.
  • NIF validation: SIGN PT may perform format-level validation of Tax ID (NIF) but does not guarantee the active or current status of a NIF with the AT unless a specific verification feature is expressly provided and used.
  • Regulatory changes: Changes in applicable laws, regulations, or AT technical requirements may require changes to the Service, the integration, the output format, or the Customer’s implementation. fiskaly may publish migration guides or implementation notices to support such changes, but the Customer remains responsible for timely implementation on its side where required.

The Customer acknowledges that lawful use of SIGN PT requires compliance not only by the Service itself, but also by the Customer’s implementation, the Taxpayer’s underlying tax data, and the final output generated through the POS or related system.

  • Responsible for activation and deactivation of the Service within its environment.
  • Responsible for integrating the API into the POS system and for staying updated and implementing required new releases, migration steps, and integration changes communicated by fiskaly where such implementation is necessary for continued use of the Service.
  • Must transmit all tax-relevant data required by the Service in the format and schema specified by fiskaly via the API.
  • Must ensure that each relevant business transaction is transmitted in a timely and continuous manner where necessary for lawful sequencing, chaining, and reporting.
  • Must operate a compatible POS system capable of receiving, rendering, and printing (or generating in PDF) the mandatory output elements for the applicable document type.
  • Where the Service interacts with the AT on behalf of the Taxpayer, the Customer/Taxpayer must provide all necessary information, credentials, permissions, sub-user access, and instructions — including for series communication and, where applicable, real-time reporting.

General compliance obligations (Customer’s and/or Taxpayer’s responsibility)

Section titled “General compliance obligations (Customer’s and/or Taxpayer’s responsibility)”
  • Visual output and layout compliance: The Customer must ensure that the final printed or PDF representation of each relevant document includes all mandatory visual and text elements required by applicable Portuguese law and by fiskaly’s written specifications, including, where applicable: the ATCUD in readable form; the QR Code in a legible form; the legally required printed hash characters/references; and the applicable certification statement and any other mandatory references. The Customer must also ensure that the output is rendered and positioned in accordance with fiskaly’s written documentation and any applicable approved layout requirements.

  • Layout implementation and approval: Where fiskaly provides written output specifications, layout requirements, or approval conditions for production use, the Customer must implement and use the relevant layout strictly in accordance with such requirements, must not use any non-approved layout in production, and must seek re-validation where changes affect mandatory elements or the approved output.

    Before any layout is used in production, the Customer must submit the implemented layout to fiskaly for written approval. A submission must include all of the following:

    • a sample PDF or print output;
    • the applicable field mapping table;
    • printer model and paper size details, where relevant;
    • test logs; and
    • implementation notes identifying any technical constraint or deviation from fiskaly’s baseline validated specification.

    A submission will only be deemed complete if it includes all of the above materials and is of sufficient quality to allow validation. fiskaly may reject an incomplete or unclear submission and request a corrected resubmission; the validation period begins only once a complete submission has been received. No layout may be used in production before written confirmation of approval has been issued by fiskaly.

    Where the Customer is uncertain whether an implemented layout complies with applicable legal or technical requirements — including due to printer-model limitations, paper size constraints, or rendering differences — the Customer must escalate the matter to fiskaly for additional validation before deploying in production.

  • Credential management: The Customer/Taxpayer is responsible for creating, maintaining, and lawfully using any AT sub-users, credentials, permissions, and mandates required for use of the Service, and for ensuring that such credentials remain valid, active, and sufficient for the intended interactions with the AT.

  • Substantive fiscal logic: The Customer/Taxpayer remains responsible for the substantive tax and business correctness of the transaction data and workflow used with the Service, including the lawful use of document types, credit/debit note logic, VAT treatment, exemption codes, tax region selection, and any other substantive tax determination not expressly validated by the Service.

  • Series handling: The Customer/Taxpayer must ensure that each relevant document series is duly created and communicated to the AT — whether through the Service/API or directly — before any document is issued under that series, and must provide any required credentials, permissions, and instructions for that purpose.

  • Data retention and production to the AT: Where SAFE or any other technical archiving functionality is used, the Customer/Taxpayer remains legally responsible for ensuring compliance with the applicable retention, accessibility, and production obligations under Portuguese law, including the ability to produce the relevant records to the AT upon request for the legally required period. Where SAFE is not contracted, the Customer/Taxpayer must ensure that an alternative compliant retention solution is in place.

  • Downstream responsibility: Where the Customer makes the Service available to taxpayers, end clients, or other third parties, the Customer is responsible for ensuring that such parties implement layouts only in accordance with the applicable approved layout specification, obtain fiskaly’s written approval before production use, and do not modify or deploy any layout contrary to fiskaly’s written specifications or approval conditions. Any act or omission of such a party that constitutes a breach of these obligations will be treated as an act or omission of the Customer for the purpose of allocating responsibility under the applicable agreement with fiskaly.

  • Indemnity for non-approved layout use: The Customer shall indemnify fiskaly for direct losses arising solely and directly from the Customer’s or any downstream party’s use in production of a layout that has not been approved by fiskaly in writing, or that has been modified after approval contrary to fiskaly’s written specifications or approval conditions. No layout may be used in production before written approval has been issued by fiskaly. This applies regardless of whether the layout is visually similar to a previously approved layout.


Version: v.3 | Last updated: 2026/05/04

Was this page helpful?