Java_NFe packages the SEFAZ NFe and NFCe web services for Java

A SEFAZ client library, not an invoicing product

Java_NFe exists so an existing Java application can speak the Brazilian tax authority web services that issue and manage the NFe and the NFCe. The README describes it as a "Biblioteca Java para consumo do WebService de NFe/NFCe", and that wording is the honest boundary of the project. Nothing in it manages products, customers, stock or prices, and there is no checkout, no storefront and no administration console. The library gives you transport to the services, generated classes for the XML layouts, the digital signature plumbing and a set of fiscal calculation helpers, and your team still owns the commercial workflow around the invoice. That makes the audience narrow: Brazilian software teams that already run a commercial system and need the fiscal document layer without reimplementing XML serialization, event handling and tax arithmetic from scratch. A company expecting a deployable invoicing product will find nothing to configure here.

JAXB classes are regenerated whenever SEFAZ changes a layout package

The mechanism is generated JAXB code bound to the official XSD layouts that the tax authority publishes. The repository carries those layouts in a schemas/ folder and ships them as schemas.zip, and the Java classes are produced from them. That one design choice explains nearly every behaviour a user notices. When a new layout package appears, the classes have to be regenerated, renamed or extended, and the changelog reads as a running record of that cycle. Layouts named in the release history include PL.009p1, PL.010b, PL.010d, PL.010e and, in version 4.2.0, PL 010f NT 2025.002 v.1.50 together with NT 2026.007 v.1.00, which also brought the new monophasic model. Event documents live in a separate package, and version 4.1.1 added tax reform event classes DetEvento110001, DetEvento112110-150 and DetEvento211110-150 as top-level types carrying @XmlRootElement. Alongside serialization, the library offers fiscal calculation helpers: IbsCbsUtil for the IBS and CBS taxes, automatic filling of item and total values, deferment calculations and a lookup of CST and Cclasstrib codes. Multithreaded operation arrived in 4.00.35, and a thread safety defect in the IBS and CBS lookup was corrected in 4.00.48.

Adding the artifact and extracting the schemas folder

Everything starts with the published artifact, which sits on Maven Central under the br.com.swconsultoria group. In a Maven project you add it with the coordinates the README shows:

<dependency>
    <groupId>br.com.swconsultoria</groupId>
    <artifactId>java-nfe</artifactId>
    <version>4.2.0</version>
</dependency>

Gradle projects use the same coordinates in an implementation declaration, br.com.swconsultoria:java-nfe:4.2.0, and for builds without a dependency manager the releases page offers a plain jar to drop into the project's libraries. The second step is the one people miss. The README asks you to download schemas.zip from the repository and extract it on your machine, and the 4.00.46 release notes repeat the warning in capitals: if you use validation, update the schemas folder. That folder is not decoration, it holds the layouts the generated classes are bound to. A first real use therefore means pointing the build at the artifact, extracting the schemas where the library expects them, and wiring one of the worked examples. The repository keeps those as test sources: EventoGenericoTeste.java for generic events, CalculosIbsCbsTeste.java for the IBS and CBS arithmetic and ConsultaTributacaoTeste.java for the tax code lookup. The full walkthrough lives in the project wiki that the README links.

Version 4.1 collapsed 48 JAXB sub-packages into two

Version 4.1 consolidated roughly 48 JAXB sub-packages into two, schemas and schemas_eventos, and renamed several event classes to remove collisions. The consequence is concrete: imports such as schema_4.enviNFe.*, schema.envEventoCancNFe.* and schema.evento112110.DetEvento no longer compile. The project answers this with an automatic migration script, documented in MIGRATION.md with a rename table and a list of breaking changes, and invoked as pwsh scripts/migrate.ps1 -ProjectRoot . -BumpPom or with bash scripts/migrate.sh. A second breaking change from the same release is quieter and just as disruptive: TProtNFe.InfProt.getDhRecbto() returns a String now instead of an XMLGregorianCalendar, so any caller that converted the value straight to LocalDateTime has to be adjusted. The release notes say the consolidation was validated in three consumer projects with 1009 tests and no failures, which is a claim about their suites rather than yours. Staying on the 4.00.x line avoids the churn, but it also freezes you on older layout packages while the tax authority moves on.

The cacert and the layout version decide whether a document is accepted

Two things decide acceptance of a fiscal document and neither is visible from the API. The first is the certificate chain. The library talks to the state tax authority endpoints over HTTPS using the Brazilian certification authorities, and the changelog records a cacert update in release after release: 4.00.37, 4.00.39, 4.00.40, 4.00.49 and 4.00.51 all carry one. If your JVM trust store does not accept that chain, requests fail before any fiscal logic runs, and the fix is to refresh the bundle that ships with the library. The second is the layout version in force. Each layout package moves the XML shape, and 4.2.0 moved to PL 010f NT 2025.002 v.1.50 and NT 2026.007 v.1.00 while earlier releases covered PL 010e, PL.010d, PL.010b and PL.009p1. Service addresses move as well: 4.00.41 changed the registry consultation URL for Amazonas, the QR Code URL for Goias and the NFCe consultation URL for Rio Grande do Norte, and earlier versions updated the SVC addresses and the NFCe web services for Ceara. A build that trails by a few months can fail on either the schema mismatch or a replaced endpoint.

Hand-written XML against the alternative of a generic HTTP client

The realistic alternative is not another library but a different shape of work: call the same web services with a generic HTTP client and assemble the XML yourself. That path avoids the schema folder and the JAXB dependency, gives you full control over the payloads, and stays workable for a single document type in a single state. It costs you everything the generated classes already encode. The tax reform events alone span many document variants, and the library ships them as named classes rather than anonymous ones after a defect in the regenerate-jaxb script was fixed in 4.1.1. On top of that you inherit the signature namespace, the correction of the package-info.java namespace that pointed at xmldsig instead of portalfiscal.inf.br/nfe, the DANFE print layout, the NFCe V3 QR Code and the IBS and CBS arithmetic. Writing all of that by hand is reasonable for one document type and unmanageable across the many layout versions the authority publishes. The trade-off also runs the other way: taking the library ties your upgrade schedule to its release rhythm and to breaking package renames, as 4.1.1 showed.

MIT licensed, release dates driven by the tax authority

The project carries an MIT licence, so commercial use and modification are permitted under those terms, and it is published to Maven Central rather than distributed only through GitHub. The repository is not archived and the last push was on 2026-10-19, the same day version 4.2.0 was published. Earlier releases came out on 2026-08-24 for 4.1.3 and 2026-08-16 for 4.1.2, and the 4.00.x line ended at 4.00.51 on 2026-03-19. The pace follows the tax authority rather than a feature roadmap, and most releases carry schema updates, cacert refreshes and fixes to the IBS and CBS calculations, such as the Cclasstrib base correction in 4.1.3 and the handling of event processing without a signature. Dependency hygiene gets attention too, with Ini4J removed in 4.00.40 over a vulnerability, so an upgrade also clears a known risk. There is no hosted tier or subscription, and the README invites collaboration through a Pix key and points to a Discord channel for questions.

Editorial conclusion

Java_NFe is worth adopting for a Java team in Brazil that already owns its commercial workflow and needs the NFe and NFCe service layer, the generated fiscal classes, the event handling and the IBS and CBS helpers. It is the wrong choice for a non-Java stack, for a company looking for a ready invoicing product, or for a team pinned to 4.00.x that cannot absorb the package renames and the getDhRecbto() return type change introduced in 4.1.1. Before adopting, check three concrete things: that the schemas folder you extract matches the layout package your state currently enforces, that your JVM trusts the cacert shipped with the version you install, and that your build can run scripts/migrate.sh or scripts/migrate.ps1 if it moves from 4.00.x. Version 4.2.0, published with the last push on 2026-10-19, is the current state of the code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Samuel-Oliveira/Java_NFe on GitHub