Laravel Algeria Invoice Laravel Package

Product Decisions This Supports

• Build vs. buy for Algeria market entry: This package covers a meaningful slice of the "document generation + tax arithmetic" layer (VAT at 19%/9%/exempt, stamp duty on cash payments, totals in centimes, amount-in-words in Arabic/French, gapless sequential numbering). The build-vs-buy question narrows to: do we own the policy layer (which rates apply, when stamp duty applies) and let the package own the rendering and arithmetic layer? That is usually the right split.
• Roadmap sequencing for a MENA/DZ launch: A working, bilingual (AR/FR) invoice artifact — invoice, credit note (Avoir), proforma — is typically a gating deliverable for signing pilot customers. This package shortens that from a multi-sprint build to an integration task, which can pull the launch date forward or free engineering capacity for the parts that actually differentiate (billing logic, payments, reporting).
• Localization and compliance as a product feature, not a chore: Arabic-first output with French and English templates, plus Arabic/French amount-in-words, is a differentiator in DZ procurement conversations. It also forces an early decision on document templates (classic, modern, minimal, plus custom-registered templates selected per call via template:) — a cheap way to offer "your branding" as a tier or add-on without new engineering.
• Scope boundary decisions: The package generates documents. It does not appear to be an e-invoicing transmission/signing layer, nor an accounting ledger, nor a payments/reconciliation system. That clarity is useful for roadmap: it tells you where the package stops and where your product must start (persistence of issued documents, immutability/archival, credit-note-to-invoice linkage, reporting).
• Pricing and packaging inputs: Per-call template selection and configurable numbering/format support multi-tenant and white-label packaging. Document-type coverage (invoice/avoir/proforma) maps cleanly onto tiered plans or usage-based billing.
• Risk decision on the stamp-duty rules: The release itself flags that several stamp-duty rules (rate application method, the 300 DZD exemption threshold, minimum, maximum, calculation base) are unresolved in available sources and are exposed as config (mode, exempt_up_to, minimum, maximum, base). This is a decision point for the PM: adopt with a documented "verify with accountant" gate, and decide who owns the compliance sign-off before any customer-facing commitment.

When to Consider This Package

Consider it when most of these are true:

• You are invoicing in Algeria (DZD) or serving Algerian customers, and need documents that reflect local VAT rates and stamp duty rather than a generic template.
• You are on Laravel/PHP and want a composer-installable dependency with migrations rather than a standalone service — the composer require + php artisan migrate installation shape means low integration cost and no new infrastructure.
• You need bilingual output now: Arabic, French, and English templates with amount-in-words are expensive to build and easy to get subtly wrong. Buying this is a clear win.
• You need the three core document types — invoice, credit note (Avoir), proforma — and gapless per-series/per-year numbering (FA-2026-00001), which is an audit expectation and a common source of bugs in hand-rolled implementations.
• Your volume and stakes are moderate: early pilots, internal tooling, SaaS MVP, back-office generation. The package is a document generator, so if you need regulated e-invoicing transmission, cryptographic sealing, or a full audit trail, treat this as one component, not the solution.
• You can tolerate a documented legal-verification step. The README's own warning about unresolved stamp-duty rules is the single most important adoption criterion: if you cannot get an accountant or local counsel to confirm the config values, do not ship customer-facing invoices on defaults.
• PDF is optional for you, or mpdf/mpdf is acceptable. PDF support is conditional on installing mpdf; if you need a different renderer, headless-Chrome pipeline, or a managed PDF service, plan for custom work or look elsewhere for that layer.

Look elsewhere, or plan to wrap rather than adopt, when:

• You operate outside Algeria or need a multi-country tax engine with maintained rate tables — this is a country-specific package, not a global tax platform.
• You require e-invoicing interoperability, tax-authority submission, or legally certified signatures. Nothing in the release notes suggests transmission, signing, or certification; those are separate build/buy decisions.
• You need accounting-grade guarantees: double-entry ledger, immutability of issued documents, retention policy, reconciliation. The package computes and renders; you must persist, lock, and archive.
• Compliance certainty is a hard gate with no room for "verify with your accountant." The open questions on stamp duty mean the defaults are not a compliance certification.
• You need mature vendor support, SLAs, or a long track record. This is v1.0.0 — first release — with a single maintainer footprint and no prior assessment history. Budget for reading the source and pinning the version.
• You need subscriptions, dunning, proration, or payment collection. Out of scope here; pair it with a billing system.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can generate legally-shaped Algerian invoices — bilingual Arabic/French, correct VAT and stamp-duty arithmetic in centimes, sequential gapless numbering, invoices/credit notes/proformas, HTML and optional PDF — by adding a small Laravel dependency instead of building it. That removes a launch blocker for the DZ market at low cost and low lock-in. The one caveat is that the package's own documentation says several stamp-duty rules are unconfirmed, so we should treat this as "90% of the way there" and book a short accountant review before we put it in front of customers. Recommended posture: adopt behind a configuration and review gate, ship to pilots, and revisit the compliance sign-off as a launch checklist item rather than a reason to build from scratch.

For engineering: Small, idiomatic surface — composer install plus migrations, config-driven stamp duty (mode, exempt_up_to, minimum, maximum, base), per-call template selection with custom templates registerable in config, three built-in themes, and PDF only if mpdf/mpdf is present. The parts we must own: persistence and immutability of issued documents, the mapping from our billing data to the package's required fields, archival/retention, and any transmission or signing. Validation messages ship in AR/FR/EN, which is a real time-saver. Because this is v1.0.0, pin the version, add tests around the total/stamp-duty calculations using our own worked examples, and isolate the integration behind our own interface so we can swap or extend the policy layer without touching call sites. Treat the unresolved stamp-duty semantics as an explicit config decision with a named owner, not a default we inherit silently.