Laravel Fatture In Cloud Laravel Package

Product Decisions This Supports

• Market entry into Italy. Fatture in Cloud is a TeamSystem-owned invoicing/accounting SaaS that handles Italian e-invoicing (SdI) and VAT rules. Wrapping it lets you ship an Italy-capable billing/invoicing flow without becoming a compliance vendor — a roadmap decision, not just an engineering one.
• Build vs. buy for compliance glue. The realistic options are: (a) integrate a certified Italian provider, (b) build SdI/XML/VAT handling in-house, (c) require customers to export/import manually. This package makes (a) cheap enough that (b) should almost always be rejected for a non-accounting product.
• Where invoicing sits in the product. Use it to decide whether invoices are generated by you (programmatic creation on order/subscription events) or synced from the customer's existing Fatture in Cloud account. Both are viable; the second is a much smaller surface area and a stronger wedge for a "we plug into your accountant's tool" story.
• Use cases it unlocks: Italian VAT-correct invoicing for SaaS subscriptions and one-off orders; marketplace/seller payouts needing per-seller documents; expense and supplier-bill sync into a finance dashboard; quote → order → invoice flows in vertical SaaS (agencies, e-commerce ops, professional services); back-office automation replacing spreadsheet exports.
• Pricing and packaging inputs. Per-company Fatture in Cloud subscriptions and API rate limits become a real COGS line if you host the account on the customer's behalf. That should shape whether you charge per-invoice, per-seat, or require the customer to bring their own account (BYO-account is usually the right default).
• Roadmap de-risking. A working integration in weeks rather than quarters tells you early whether Italian demand is real, before you commit to a native compliance module.

When to Consider This Package

Adopt when most of the following hold:

• Your stack is Laravel/PHP and you already have, or are willing to require, a Fatture in Cloud account as the invoice system of record.
• You need a narrow, event-driven surface: create/read customers, products, invoices, suppliers, receipts; fetch PDFs; reconcile status. Not a full accounting engine.
• Italy is one market among several, so you want a regional adapter rather than a core-domain rewrite.
• You have no in-house Italian tax expertise and no appetite for SdI accreditation, XML schema churn, or VAT edge cases.
• You want MIT-licensed, low-ceremony glue you can read in an afternoon and fork if needed.

Look elsewhere when:

• Stack mismatch. Not Laravel, or a service-oriented architecture where a PHP-only wrapper creates a polyglot mess — use the upstream REST API directly from whichever service owns invoicing.
• Multi-country e-invoicing. One provider, one country. If you need PEPPOL/Europe-wide or US/APAC tax, choose a global tax engine and treat Italy as a connector inside it.
• You need SLAs, support contracts, or vendor indemnity. This is a community wrapper, not a supported SDK — the commercial relationship is with Fatture in Cloud, not with this package.
• Consequence-heavy volume or bespoke flows. High invoice volume, complex multi-entity consolidation, custom approval chains, or heavy webhook/event processing: budget time to verify endpoint coverage and consider owning a thin client yourself.
• Accounting, not invoicing. If the requirement is ledgers, reconciliation, payroll, or statutory reporting, you need a different category of product.
• Maintainer risk is unacceptable. A ~10-star, single-maintainer package is a concentration risk. Acceptable for a thin adapter behind your own interface; not acceptable as a load-bearing dependency in a regulated flow without a fork-and-own plan.

Diligence checklist before committing: confirm the endpoints you need actually exist in the wrapper (or fall back to the underlying client), check token refresh/OAuth handling, check error and rate-limit behavior, pin the version, and confirm the maintainer's release cadence against your support window.

How to Pitch It (Stakeholders)

To executives: Italy mandates electronic invoicing, and every Italian SMB already uses a compliant provider — Fatture in Cloud is one of the largest. This package lets our Laravel product create and read invoices in those accounts in days, not quarters, with no in-house tax or compliance build. It converts "can we sell in Italy?" from an engineering program into a scoped integration with a per-customer subscription cost we can price for. The license is MIT and the library is small, so downside is bounded: worst case we replace the adapter, not the product.

To engineering: It's a thin, idiomatic Laravel wrapper over the Fatture in Cloud API v2 — service provider, config, facade, resource classes for the main entities, and token handling. It keeps HTTP and DTO noise out of your domain code. Two asks: (1) wrap it in our own InvoicingGateway interface so the vendor and the package are both swappable; (2) treat it as a thin client — verify endpoint coverage for our specific flows, pin versions, and own error/retry behavior rather than assuming it. Small community means we should be comfortable forking.

To finance/ops: We gain programmatic invoicing that is compliant by construction in Italy, with the customer's own provider account (BYO-account) keeping the compliance relationship and the subscription off our P&L.