Laravel Notas Fiscais Laravel Package

Product Decisions This Supports

• Build vs. buy on fiscal document issuance (NF-e / NFS-e): this package is the "buy/adopt" lane for teams that want fiscal emission inside their own Laravel app rather than a full ERP or a hosted fiscal API. The driver-per-municipality model is the key architectural bet to evaluate: it accommodates the reality that Brazilian municipal webservices have no single contract.
• Multi-municipality / multi-tenant go-to-market: the per-driver abstraction directly enables expansion from a single city to a municipality-by-municipality rollout. Roadmap sequencing (which cities to enable next) becomes a "write one driver" decision rather than a re-architecture.
• Cloud and network topology decisions: the v1.2.0 addition of outbound proxy per driver is a product-relevant constraint, not an implementation detail. Some municipal webservices require a national (Brazilian) source IP, which rules out hosting in us-east-1 with shared egress. This shapes infra choices — static egress IPs, a Brazilian region/VPC, or a per-driver proxy pool — and must be priced into the deployment cost model before committing to those municipalities.
• Support and compliance scoping: because each driver is an independent integration surface, support tiers and SLA commitments can be defined per municipality/state. This informs which segments (e.g. service businesses in cities with IP-whitelisting requirements) are supportable today versus deferred.
• Operational risk for fiscal issuance: tax documents are legally binding and time-sensitive. The package reduces vendor lock-in and per-document API fees, but transfers responsibility for certificate handling, contingency/offline mode, and municipal schema changes in-house. That trade-off belongs in a documented risk register, not an ad hoc engineering choice.
• Use cases it fits: SaaS platforms issuing service invoices at scale, marketplaces that must emit on behalf of sellers in multiple municipalities, and internal back-office tooling where finance already lives in the Laravel app.

When to Consider This Package

Consider adoption when:

• You are on Laravel/PHP and intend to keep fiscal emission inside your own codebase rather than outsourcing to a fiscal-as-a-service provider.
• You operate in, or plan to enter, multiple Brazilian municipalities and expect the list to grow — the driver model is the value proposition, and a single-city deployment gets less benefit from it.
• You have, or are willing to build, in-house competency in digital certificate (A1) management, XML signing, SOAP/mTLS transport, contingency mode, and tax-rule validation. This package is plumbing, not a compliance guarantee.
• Your hosting strategy can accommodate Brazilian egress IPs, whether via a national region or per-driver outbound proxies as introduced in v1.2.0. Confirm this before scoping municipalities that enforce IP restrictions.
• You accept vendor-maintenance risk on drivers: each driver tracks a third-party webservice that can change schemas, endpoints, or requirements without notice.

Look elsewhere when:

• You need turnaround-grade fiscal support and SLAs and cannot staff on-call for emission failures — a commercial fiscal API or ERP integration is the lower-risk answer.
• You need broad municipality coverage immediately. Verify the actual driver list against your target cities; a small driver set means significant per-city engineering before launch.
• Your stack is not Laravel/PHP, or you have no appetite for managing certificates and signing pipelines yourself.
• You require audited compliance certifications or vendor indemnification for rejected documents.

How to Pitch It (Stakeholders)

For executives: This is an open-source Laravel package that lets our product issue Brazilian fiscal documents (NF-e/NFS-e) directly, instead of paying a fiscal API per document or forcing customers onto an ERP. Its design — one pluggable driver per municipality — is what makes multi-city expansion a repeatable engineering task rather than a series of one-off integrations. The v1.2.0 release adds per-driver outbound proxy support, which unblocks municipalities that only accept traffic from a Brazilian IP address; that is a real market-access constraint we would otherwise have hit at launch. The trade-off is explicit: we take on certificate management and fiscal contingency ourselves, so the value case rests on volume (per-document fees avoided) and on strategic control of the issuance flow. I recommend a scoped pilot in one or two target municipalities with a documented fallback to a commercial provider, and a decision gate on infra cost for national egress before we commit to the full city roadmap.

For engineering: Adopt the driver abstraction as the integration boundary — no municipality-specific logic outside a driver. Prioritise hardening around certificate lifecycle, signing, retry/contingency behaviour, and schema-drift monitoring, since those are the failure modes that reach customers. Treat the new proxy configuration as a first-class per-driver capability: it needs configuration management, credential handling, and health checks, not just a config key. Plan for driver-level test fixtures, because we cannot rely on municipal sandboxes.