- Does cleverit/ubl_invoice work with Laravel 11 and PHP 8.2?
- No, not unmodified. The last release was 2019-02-05, which puts it in the Laravel 5.6-5.8 and PHP 7.1-7.2 era, and its composer.json platform constraints typically block installation on PHP 8.1+. You need to fork it and raise the PHP constraint, vendor the XML-building classes into your app, or pick a maintained alternative.
- How do I install cleverit/ubl_invoice in a Laravel application?
- The nominal install is a standard Composer require of cleverit/ubl_invoice, but on any modern PHP runtime that will fail platform checks or pull stale transitive Symfony and DOM dependencies. Installing with --ignore-platform-reqs is not a viable strategy because it converts a pinned dependency into an unpinned liability. The realistic route is to fork the repository into a private VCS, raise the constraints, and require your fork.
- Is cleverit/ubl_invoice still maintained?
- No. There has been no release in roughly six years, the project sits at around 36 stars, and there is no active issue triage, CVE response, or PHP 8 compatibility work. The bus factor is effectively zero, so treat any fork you create as first-party code with a named owner and a documented upgrade path.
- Which UBL version and CIUS profile does cleverit/ubl_invoice target?
- It targets the UBL 2.1 era from around 2019, which predates the PEPPOL BIS 3.0 rule sets and the CIUS profile changes that followed. UBL 2.1 itself is stable, but national profiles have added mandatory fields and changed cardinalities since then. Verify the exact target profile in the source before relying on it for a specific jurisdiction or access point.
- Does cleverit/ubl_invoice validate invoices against XSD or Schematron rules?
- No. The package is a serializer: it builds the UBL XML payload but does not perform XSD or Schematron validation. That means a document can generate without errors and still fail validation downstream at the PEPPOL access point, the customer, or the tax authority. You must add your own validation step against the relevant rule set.
- Does cleverit/ubl_invoice support XMLDSig digital signatures?
- No. Enveloped XMLDSig signatures and validation are out of scope for a serializer of this vintage. If your jurisdiction or access point requires a signed payload, you have to implement signing and canonicalization yourself or hand the document to a gateway that does it for you. Budget for that work separately from generation.
- How should I integrate cleverit/ubl_invoice into a Laravel codebase?
- Use an anti-corruption layer: define an InvoiceXmlGenerator interface in your domain and implement it with a CleverItAdapter that wraps the vendored or forked classes, so nothing else in the codebase references the package directly. Build party, line, tax total, and payment means DTOs from your invoice aggregate, serialize to XML, persist the artifact, then hand off to a PEPPOL access point or e-invoicing gateway, typically from a queued job. That keeps the eventual replacement a one-class change.
- What are the alternatives to cleverit/ubl_invoice for Laravel projects?
- Actively maintained options include horstoeko/ubl for UBL documents and horstoeko/zugferd for ZUGFeRD and Factur-X. A commercial PEPPOL access point that includes document construction is another route that offloads compliance. If you stay with cleverit/ubl_invoice, treat it as a reference implementation rather than a long-term dependency.
- Does cleverit/ubl_invoice handle credit notes, self-billed invoices, and allowances or charges?
- Coverage beyond the happy-path commercial invoice is not documented in the overview and should be verified by reading the source. Credit notes, self-billed invoices, and allowance or charge lines each have different cardinalities and mandatory elements under UBL 2.1 and modern CIUS profiles. If your billing model needs them, write tests against official sample documents before committing to the package.
- How do I test UBL XML generated by cleverit/ubl_invoice?
- Add a golden-file test suite that asserts generated XML against official UBL 2.1 sample documents and the Schematron rule set for your target CIUS. Run it in CI on every change to the fork so specification drift is caught at generation time rather than at the access point. Pin the fork to a specific commit and record the UBL and CIUS version it targets in the repository README.