Xero Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for accounting integration. Xero connectivity is a recurring roadmap ask anywhere invoices, bills, contacts, or payments touch finance. This package represents the "buy/borrow" option at the cheapest end: a thin Symfony service-container wrapper around calcinai/xero-php. Evaluating it forces the real decision — do we own an integration layer, or do we route through a hosted middleware (Zapier, Parcel, Cledo, an iPaaS) and keep our codebase clean?
• Scoping the finance surface area. The underlying SDK exposes the full Xero API (accounting, contacts, invoices, credit notes, bank transactions, attachments). That tells you what is technically reachable in one sprint versus what should be phased: read-only contact/invoice sync first, write-back and reconciliation later.
• Platform/infrastructure fit. This is a Symfony bundle, not a Laravel package — a meaningful correction to the brief. If our stack is Laravel, the bundle's value proposition evaporates (no bundle auto-discovery, no Symfony DI), and the decision collapses to "use the SDK directly." That distinction alone can save a sprint of mis-scoped work.
• Dependency risk budgeting. Two stars, zero dependents, last release July 2018. This is a data point for the risk register, not a feature decision: any finance-adjacent dependency must be evaluated for OAuth token handling, credential storage, and API-version drift before it goes near production.
• Roadmap sequencing for multi-platform support. If QuickBooks or Sage is also on the horizon, deciding now whether to standardise on one SDK-per-provider or an abstraction layer changes the architecture of the whole finance module.

When to Consider This Package

Consider it only if all of the following hold:

• The application is genuinely Symfony (3.x/4.x era, PHP 7.x) and you want container wiring for the Xero client with minimal ceremony.
• You are comfortable forking and owning it. At two stars and a 2018 release, treat it as a reference implementation or a starter skeleton you vendor into your repo — not a dependency you composer require and forget.
• Your integration is narrow and stable: push invoices, pull contacts, no webhooks, no complex tenant/OAuth2 refresh flows.
• You have an engineer who can read ~a few hundred lines of glue code and take responsibility for it.

Look elsewhere if:

• You are on Laravel. Use calcinai/xero-php directly behind a service class, or a maintained Laravel-specific wrapper. Do not adopt a Symfony bundle for DI convenience you will not get.
• You need production support or SLAs. There is none here.
• OAuth 2.0 / token refresh / multi-tenant connections matter. Xero retired OAuth 1.0a; a 2018 wrapper is unlikely to have kept pace, and the failure mode is broken auth in production, not a clean error.
• Finance data is in scope for audit/compliance review. An unmaintained dependency handling credentials and financial records is a hard sell to security, regardless of how small it is.
• You expect the integration to grow. Webhooks, attachments, payroll, and multi-org support will outrun this wrapper quickly.

How to Pitch It (Stakeholders)

To executives: This is not a package we should adopt. It is a five-year-old, two-star Symfony wrapper with no dependents and no maintenance — a useful reference for how little code a Xero integration actually requires, and a useful warning about how quickly finance integrations rot. The strategic point: Xero connectivity is a small, well-understood integration we can own deliberately, not a large build we should avoid. Recommendation is to budget one engineer-sprint for a thin in-house client on top of the actively maintained calcinai/xero-php SDK (or a hosted middleware if we want zero maintenance), and to close out this evaluation as "considered, rejected on maintenance risk."

To engineering: The bundle is DI glue, not functionality — everything real lives in the underlying SDK. Porting the useful parts is hours, not weeks. The genuine risks are OAuth 2.0 token lifecycle, credential storage, and Xero API versioning, none of which this package addresses in its 2018 state. If we go in-house, we own those explicitly, which is the better outcome.