Download the PHP package einvoicing/laravel without Composer

einvoicing/laravel

Peppol e-invoicing for Laravel: validate, convert and look up documents with the einvoicing.dev API.

It wraps einvoicing/sdk in the things a Laravel application already expects — a config file, a facade, a validation rule, Artisan commands, cached lookups and a testing fake — so nothing here needs a wrapper of your own.

Install

Requires PHP 8.4 and Laravel 13.

Pin the ruleset. Leave it out and validation follows whatever release is current, which means a change elsewhere can turn a passing build red without anything of yours changing.

Validating

An invalid document is a successful call. The report carries every finding, not only the first — the second one is usually the interesting one.

As a validation rule

Each error becomes its own message, naming the rule and quoting the fix. Warnings are ignored unless you ask for them: new PeppolDocument(warningsFail: true).

Converting your own data

Totals and the VAT breakdown are worked out from the lines, and the result is validated before it is returned. An invoice that cannot produce a valid document throws InvalidInvoiceException, whose findings() say why.

Looking a participant up

Lookups go through Laravel's cache — five minutes by default, matching the API's own caching. A participant who moves Access Point keeps their identifier, so re-check with Einvoicing::participant($id, fresh: true) when a send fails.

Two traps the SDK handles for you. A business absent from the optional Peppol Directory may still be registered and reachable, so directory being null means nothing on its own. And a UK VAT number is registered with or without its GB prefix, as two different participants; the lookup tries both and reports the form that answered. Store that form.

From the command line

einvoicing:validate exits non-zero on an invalid document, so it drops into CI as it stands.

Testing

Nothing leaves the machine once the fake is installed. Documents come back valid and participants come back registered unless you say otherwise, because the interesting tests are the ones where you say otherwise:

And the assertions:

The HTTP client

This package names no HTTP client. The SDK discovers the PSR-18 client and PSR-17 factories from whatever your application has installed, so there is nothing to configure.

Most Laravel apps already have Guzzle, since that is what the Http facade uses, and that is all discovery needs.

If yours does not, allow the discovery plugin and composer installs a pair for you — it asks on install, and saying yes is enough:

or install one yourself:

Decline the plugin and install nothing, and the install still succeeds — nothing checks at that point — but the first request throws NoHttpClientException.

To supply your own — an instrumented client, a proxy, a different timeout — replace the whole client rather than the pieces inside it:

One override point, and it is the object the facade actually uses. Binding ClientInterface on its own does nothing here — discovery is the mechanism, not the container.

Errors

Every failure is an Einvoicing\Exceptions\EinvoicingException: UnauthenticatedException, AllowanceExhaustedException, RateLimitedException (with retryAfter()), NotFoundException, InvalidInvoiceException (with findings()), ProblemException and TransportException. Branch on $e->type or $e->slug(), never on the title or the detail — those are prose for a human reading a log.

Development

Licence

MIT.