wmixvideo/nfe handles the XML side of Brazilian e-invoicing so you do not have to

The library takes over transport, not tax policy

The scope statement is unusually honest for a fiscal library. It covers building the XML, signing it, validating it against the schemas and talking to the SEFAZ webservices for NF-e, NFC-e, CT-e and MDF-e. What it does not do is decide the fiscal content of the document. CFOP, CST, tax rates and similar codes depend on the operation and on legislation, and the project points readers at an accountant when in doubt. That boundary is the single most useful thing to know before writing any code against it. It means the library is a serialization and transport layer that mirrors the official XML structure, not a business rules engine, and a team that expects the second will be disappointed. The official documentation is treated as the primary source of truth, with links to the Portal Nacional da NF-e, the Portal Nacional do CT-e and the MDF-e portal, plus a page of common questions for newcomers.

Config, document, facade: three steps for every document type

The usage path is the same for every fiscal document, and it is worth internalising because it repeats. First you extend a configuration class, `NFeConfig` or the CT-e and MDF-e equivalents, supplying the state of the issuer, the environment, the certificate and the certificate chain. Second you assemble the document with the library's Java classes, which mirror the official XML, with `NFNota`, `CTeNota` and `MDFe` named in the documentation. Third the `WSFacade` signs the document, validates it against the XSD and transmits it to SEFAZ, returning the response already converted into Java objects. Each document type has its own facade, and the package names carry the schema version, so the NF-e and NFC-e facade lives under `com.fincatto.documentofiscal.nfe400.webservices`, CT-e under `com.fincatto.documentofiscal.cte400.webservices`, and MDF-e under `com.fincatto.documentofiscal.mdfe3.webservices`. That versioning in the package name is the clearest signal that schema changes propagate into your import statements.

Adding the dependency and compiling from source

Requirements are modest on the Java side and heavier on the infrastructure side. You need Java 11 or newer, and you need an A1 digital certificate in `.pfx` or `.p12` form, or an A3 certificate, and that applies to the homologation environment as well. The dependency goes into a Maven `pom.xml`, with the version replaced by the latest published release listed on Maven Central under the artifact `com.github.wmixvideo:nfe`:

<dependency>
    <groupId>com.github.wmixvideo</groupId>
    <artifactId>nfe</artifactId>
    <version>VERSAO</version>
</dependency>

To work against the development version instead, the project documents building from the source tree:

git clone https://github.com/wmixvideo/nfe.git
cd nfe
mvn clean install

The build publishes to Maven Central through the standard Maven tooling, and the repository is also built with Maven given the `pom.xml` at the top level and a `src/` directory. Release notes for each version live in the GitHub releases, which is where you would look to see what changed between the version you depend on and the newest one.

Your config class decides the environment, and the default is not production

A configuration class extends the base type and overrides what it needs. The mandatory methods concern the state, the certificate and the certificate chain; everything else has a default you can overwrite. The detail that matters most is the environment. The default value is the homologation environment, and to issue documents with fiscal value you override `getAmbiente()` and return `DFAmbiente.PRODUCAO`. Getting this wrong in either direction is expensive, so it is the first thing to check in a new integration. A minimal override looks like this:

    @Override
    public DFUnidadeFederativa getCUF() {
        return DFUnidadeFederativa.SC;
    }

    @Override
    public DFAmbiente getAmbiente() {
        return DFAmbiente.HOMOLOGACAO;
    }

Other overridable methods cover emission type, defaulting to `EMISSAO_NORMAL` for normal or contingency emission, the certificate alias inside the KeyStore, defaulting to the first alias found, the CSC and its ID, which are mandatory for NFC-e and default to `null`, the time zone used for dates, defaulting to the JVM time zone, and the request and socket timeouts for the SEFAZ calls, whose defaults live in `DFConfig`.

The SEFAZ certificate chain is fetched for you, but it expires

Beyond the issuer certificate, communication with SEFAZ depends on the chain of certificates belonging to the SEFAZ servers. The library handles that step: it downloads the chain and produces the JKS file for you, per environment.

byte[] producao = DFCadeiaCertificados.geraCadeiaCertificados(DFAmbiente.PRODUCAO, "senha_da_cadeia");
Files.write(Paths.get("/caminho/cadeia-producao.jks"), producao);

The same call with `DFAmbiente.HOMOLOGACAO` gives you the homologation chain, written to its own file. The operational warning is that SEFAZ rotates its certificates from time to time, so SSL and handshake errors usually mean the chain is stale and needs to be regenerated rather than that something is wrong with your code. A second expiry risk sits on your side: an A1 issuer certificate typically stays valid for about a year, so a working integration still needs a renewal path. The library cannot hide either of these, and they are the two maintenance items most likely to interrupt a production issuer.

Certificates stored in the Windows repository need a different KeyStore path

Not every issuer keeps its certificate as a file. A3 certificates installed in the Windows certificate repository are reached through the `Windows-MY` KeyStore, and the documentation shows the same override pattern with the store type changed, selecting the wanted certificate by its alias. The point for an integrator is that the KeyStore type is part of the configuration contract, not an implementation detail of the platform, so the same code base has to branch between `PKCS12` for a `.pfx` file, `JKS` for the chain file, and `Windows-MY` for an installed certificate. That branching lives in your own configuration subclass, which means the library gives you one hook and your team decides the policy.

Where a hand-rolled SEFAZ client differs

The alternative to this library is to talk to the SEFAZ webservices yourself: build the XML to the official schema by hand, sign it with your own XML digital signature code, validate it against the XSD yourself, manage the certificate chain download and unpack the SOAP responses into your own objects. The difference in approach is entirely in the assembly and transport layer. This library supplies classes that mirror the official XML structure, performs signing and XSD validation, handles the certificate chain, and returns converted Java objects, so the work left in your code is the fiscal decision rather than the protocol. The cost of that convenience is that the versioned facade packages are part of your public dependency surface, so an upgrade of the library can change an import path, and the project keeps its own release notes for exactly that reason. A team that already owns a signed, validated SEFAZ client has little to gain here, while a team starting from a blank Java project has a great deal to skip.

Release cadence and the Apache 2.0 boundary

The current release is v5.1.7, published on 2026-10-16, with v5.1.6 on the same day and v5.1.5 two days earlier, and the last push was on 2026-10-16 as well. Releases this close together point to a project that ships corrections as they arrive rather than to a slow, scheduled release train, which matters if you pin a version in a long-lived application. The licence is Apache 2.0, a permissive choice that does not restrict commercial use of the library in an issuer's own product, though the library's own obligations and any trademark or brand considerations around SEFAZ names are separate questions that the licence file itself answers. The project is presented as collaborative, with a WhatsApp group for discussion about the library's development, and the documentation is part of the repository under `docs/`, including a page of common questions for those starting out.

Editorial conclusion

Use wmixvideo/nfe when you need a Java client that produces signed, schema-valid NF-e, NFC-e, CT-e or MDF-e documents without writing the XML and certificate plumbing by hand. Do not use it to decide CFOP, CST, tax rates or any other fiscal rule, since it deliberately leaves those out. Verify first that your Java runtime is 11 or newer, that your A1 or A3 certificate loads, and that the facade package you import still matches the version you are upgrading to.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. wmixvideo/nfe on GitHub