sped-nfe: PHP Generation and Communication of NFe and NFCe

The SPED NFe Integration Boundary

sped-nfe addresses a specific part of Brazilian electronic invoicing: constructing NF-e and NFC-e data, digitally signing it, and communicating it to the relevant SEFAZ authorizing environment. Its intended users are PHP applications that need programmatic control over fiscal document generation rather than a general-purpose accounting package. The README states that all model 55 NFe states and all model 65 NFCe states are covered.

The package also supports NFCe issuance by an individual taxpayer through eCPF. That support has geographic limits documented by the project. Ceará, Paraná, and São Paulo do not accept issuance with eCPF, while communication problems prevented the project from confirming the situation in Amazonas and Goiás. For other states, the README says they apparently accept eCPF issuance. This wording is not equivalent to a state-by-state compatibility guarantee, so an integrator must still verify the intended jurisdiction.

The repository includes PHP examples for NFCe, registration, cancellation, status checks, distribution of DF-e, delivery events, text conversion, and schemas associated with the Reforma Tributária da Consumo. It is therefore aimed at developers integrating electronic fiscal documents into an application, not users who only need a human-readable invoice layout.

Make, Signing, and SEFAZ Communication

The package describes itself as a library that supplies the means to generate, sign, and transmit SPED NFe data. Its examples use classes such as `NFePHP\NFe\Make`, while the repository also contains SEFAZ-related examples for cancellation, status, and taxpayer registration. Based on the repository layout, these concerns are separated into source code, schemas, console utilities, fixtures, and examples rather than being implemented as one command-line application.

The XML side includes named schema and fixture files for several layout packages, including `PL_010B`, `PL_010C`, and `PL_010E`. The README also lists schema packages and technical notes concerning NFCe QR Code version 3, alphanumeric CNPJ, validation changes, GTIN validation, agricultural and forestry product information, fuel taxation, and Reforma Tributária da Consumo. This indicates that document validity depends on fiscal layout data that changes independently of application code.

The basic README example only constructs a `Make` object. It does not document the complete path from an empty object to a signed transmission, nor does it provide an end-to-end explanation of certificate loading, XML assembly, protocol attachment, or response handling. The repository's examples and `docs/Funcionalidades.md` are therefore necessary references for implementing those stages. The short introduction should not be mistaken for complete integration documentation.

Composer Installation and Namespace Loading

The documented installation method is Composer, and the README explicitly says that no alternative installation procedure is provided. Install the stable package with the following command:

composer require nfephp-org/sped-nfe

Composer then registers the package and its dependencies in the application. An application can instead declare the package in `composer.json`, using the constraint shown by the project:

"require": {
    "nfephp-org/sped-nfe" : "^5.0"
}

The package uses namespaces and PSR-4 autoloading. The README presents a direct `require` of `sped-nfe/src/Make.php` as incorrect because it bypasses the intended object-loading approach. For the documented first use, load Composer's generated `autoload.php`, import `NFePHP\NFe\Make`, and instantiate it:

require VENDOR_DIR . 'autoload.php';

use NFePHP\NFe\Make;

$nfe = new Make();

`VENDOR_DIR` is described as the application's `vendor` directory. In a normal installation it would need to contain the full filesystem path, with platform-specific separators if necessary. The sample establishes class loading and object creation only. It does not define an NFe, sign it, or send it to SEFAZ.

Developers who deliberately want the development branch can request `dev-master` instead:

composer require nfephp-org/sped-nfe:dev-master

That branch has a separate Composer consequence. The README says `minimum-stability` must be changed from `stable` to `dev`:

"minimum-stability": "dev"

This changes dependency resolution for the application, so the development branch should not be selected merely because it contains newer layout updates.

PHP Extensions and Contributor Environment

The runtime requirements are broader than a basic PHP class library. The README lists PHP 7.x while calling PHP 7.4 the minimum, although it also says to check the badges. It further lists `ext-curl`, `ext-dom`, `ext-json`, `ext-gd`, `ext-mbstring`, `ext-mcrypt`, `ext-openssl`, `ext-soap`, `ext-xml`, and `ext-zip`, plus the `sped-common` package. A deployment that lacks one of these components is outside the package's documented environment.

There is an ambiguity worth resolving before adoption. The requirements mention `ext-mcrypt`, while the contribution instructions prefer PHP 8.2 or 8.3. The README does not reconcile those statements or document substitutions. The actual `composer.json`, installed PHP version, and project badges should be checked for the selected release or branch.

A development environment is defined through `docker-compose.yml`. It names an `app` service, builds `docker/php/Dockerfile`, mounts the repository at `/var/www/sped-nfe`, and starts Bash. The file does not document an invocation command, so none can be copied from the project information. The repository's contribution instructions instead tell contributors to execute `composer install` at the project root and state a preference for PHP 8.2 or 8.3.

Fiscal Layout Updates as Upgrade Cost

The maintenance picture has two separate dates and they should not be conflated. The last push was on 2026-10-02, which is recent relative to the repository state, and the project is not archived. However, the only listed release is `v5.0.100`, dated 2020-03-12. Repository activity therefore does not establish that the stable release or its packaged schemas are equally current.

The README lists updates through 2025 technical notes and schema packages, including `PL_010v1.10b`, `PL_010v1.20b`, `PL_010C`, and an XSD for alphanumeric CNPJ. This creates a real upgrade and verification cost. An integrator must determine which layout applies to each document type, issuance date, state, taxpayer situation, and fiscal reform rule. Installing the newest branch does not by itself prove that an application constructs the required XML correctly.

For production changes, compare the selected release or branch, `VERSION.txt`, `CHANGELOG.md`, and the files under `schemes/`. The examples include multiple schema families rather than one universal fixture, which reinforces that fiscal layout is versioned data. Migration testing should preserve known-good XML fixtures and compare generated structures, but the README does not claim compatibility with every application upgrade.

Optional work is split into related packages rather than included in the core scope. The README names `sped-da` for printable documents, `sped-mail` for email, `sped-ibpt` for approximate consumer-sale taxes, `sped-gnre` for GNRE, and `posprint` for thermal printer output. That separation can keep a core application smaller, but it means a complete business workflow may require several dependencies.

License Review and Operational Boundaries

GitHub classifies the repository license as a custom license, and the project includes `LICENSE.md`. Because that file's terms were not provided in the repository information, its permissions, restrictions, redistribution conditions, and warranty language cannot be characterized. This is a direct licensing review item for an adopting organization rather than an assumption that the package is equivalent to a standard open source license.

The package is not a general SEFAZ integration service. It requires the issuing taxpayer to supply the operational context that the library cannot establish by itself, such as the applicable state authority, taxpayer data, digital certificate material, and valid service configuration. The README and examples do not provide a complete production checklist for storing or rotating certificate files. Code touching credentials should therefore remain outside the repository, while the project's contribution instructions recommend a local directory for sensitive data.

A practical boundary also exists around printed documents. Core sped-nfe generates and communicates fiscal XML data, while DANFE, DACTE, email delivery, approximate tax consultation, GNRE, and POS printing belong to separate packages. Users expecting one dependency to produce a complete outbound document set will not get that result from this repository alone.

The eCPF support is another boundary. It exists for NFCe in many jurisdictions according to the README, but the documented exclusions and unverified states prevent a blanket claim. Applications serving multiple states need explicit checks for each target authority instead of treating eCPF as universally accepted.

Adoption Choice Against Direct PHP Work

The real alternative is to implement NFe construction, XML signing, schema handling, and SOAP communication directly in an application or use a proprietary fiscal platform. Direct PHP work gives the integrator complete control over the integration boundary, but it also places responsibility for every fiscal layout, transport detail, validation response, and protocol state inside the application.

sped-nfe removes much of that repetitive fiscal-document code by supplying a PHP package, current layout-oriented schemas, SEFAZ-oriented classes, and examples for common operations. Its approach differs from a managed API product because tax authority access and taxpayer authorization remain operational responsibilities of the deployment. It is also more specialized than a generic XML library, since its classes and schemas are tied to the NFe and NFCe domain.

The trade-off is documentation depth. The README calls the documentation process an early stage, while the basic usage sample stops at object construction. A team adopting this project should inspect the relevant example, `docs/Funcionalidades.md`, `schemes/`, and configuration expectations for its state before designing a service around the package. Repository badges do not establish production suitability, and this review does not claim that any environment or SEFAZ connection was tested.

Editorial conclusion

PHP developers responsible for NFe or NFCe issuance should adopt sped-nfe when they can operate Composer, the required PHP extensions, and changing fiscal layouts. It is a poor fit for a simple PDF generator, a manual API client, or a team that cannot track SEFAZ technical notes. Before adoption, verify the PHP version, extension availability, licensing terms in `LICENSE.md`, certificates and credentials for the target state, and compatibility with the exact schema required for the documents being issued.

Frequently asked questions

Official sources

1. Issues
2. nfephp-org/sped-nfe on GitHub
3. README
4. Releases