Laravel Ifrs Laravel Package

Product Decisions This Supports

• Build vs. buy for ledger/VAT plumbing. This package already models accounts, line items, VAT rates, account schedules, and trial-balance-style reporting. If your roadmap includes invoicing, billing, or any double-entry bookkeeping, adopting it converts a multi-sprint build into an integration task and lets engineering spend its time on the product surface instead of accounting primitives.
• Feature feasibility: tax-aware billing. The presence of a dedicated Vat model and LineItem amounts/quantities/rates means VAT-aware line-item computation and reporting are in scope without custom schema design. Useful for pricing EU/UK-facing invoicing features.
• Financial reporting features. AccountSchedule (age-based calculations) and Trial Balance behaviour are the building blocks for receivables aging, period-close summaries, and accountant-facing exports — the kind of feature that usually justifies an enterprise tier.
• Roadmap constraint: runtime baseline. v6 requires PHP 8.2+ and Laravel 11/12/13. This is a direct input to your platform-upgrade planning: if any production service (or a customer's self-hosted deployment) is still on Laravel 10 or PHP 8.1, adopting v6 forces that upgrade first. Decide whether to pin to v5 for those surfaces or accelerate the platform upgrade.
• Roadmap opportunity: Laravel 13 readiness. v6 ships Laravel 13 compatibility ahead of the ecosystem. If your platform strategy is "stay on current Laravel," this package is not a blocker for the next major upgrade cycle — a real schedule saver.
• Maintenance-cost modelling. The release shows sustained investment: a PHP 8.2/8.3/8.4 CI matrix, deterministic test suite, driver-portability fixes. That supports a "buy/maintain" assumption rather than a "fork it and own it" assumption.
• Risk decision: SQLite-backed deployments. The remove_vat_id_column fix drops a foreign key before the column so Laravel 11+ table rebuilds work on modern SQLite. That bug could leave a migration half-applied and a schema in an inconsistent state — relevant if you support SQLite in dev, CI, or single-tenant on-prem installs. It also argues for testing migrations against every driver you actually ship, not just MySQL.

When to Consider This Package

Consider it when:

• You need accounting primitives — chart of accounts, line items, VAT — as a domain layer inside a Laravel app, not a full ERP.
• You are on, or are willing to move to, Laravel 11/12/13 on PHP 8.2+. This is now a hard gate; there is no 8.1 path in v6.
• Your team is Laravel-fluent and will read the source. This is a package you integrate and extend, not a black box with a REST API.
• You value upstream maintenance discipline: seeded PRNG in tests, pinned execution order, a multi-PHP CI matrix, and driver-specific migration correctness are all signals of a maintainer who will accept your bug reports.
• You want VAT and trial-balance semantics handled by someone who has already hit Carbon 3's signed-float diffInDays() behaviour and modern SQLite's foreign-key strictness — edge cases you would otherwise discover in production.

Look elsewhere when:

• You need a hosted, audited, compliance-certified tax engine (e.g. jurisdiction-specific VAT/MTD/e-invoicing filing). This is application infrastructure, not a compliance product.
• You are pinned to Laravel 10 / PHP 8.1 with no upgrade path this year. You would be adopting a version the maintainer no longer supports, and backporting the SQLite and Carbon 3 fixes yourself.
• You need multi-currency consolidation, sub-ledgers, or intercompany accounting at scale — that is ERP territory.
• You require a vendor SLA, indemnification, or commercial support contract. Treat this as open-source with community support; budget internal ownership accordingly.
• Your reporting needs are read-only analytics over an existing ERP. You would be duplicating a system of record.

Upgrade note for existing v5 users: v6 is a clean breaking release (PHP floor, Laravel 10 dropped). Plan it as a scheduled platform upgrade, not a patch bump — validate migrations across every database driver you ship, and re-run financial regression tests, since the Carbon 3 age-calculation fix can change AccountSchedule output for edge-case dates.

How to Pitch It (Stakeholders)

For executives: This is mature, actively maintained Laravel infrastructure that gives us accounting and VAT capabilities — accounts, line items, tax rates, aging schedules, trial balance — without building them from scratch. That is roughly a quarter of engineering effort redirected toward customer-facing features. The new v6 release keeps us current with the latest Laravel and PHP, and the maintainer is demonstrably rigorous about correctness in financial calculations and database migrations. The trade-off is a platform requirement: PHP 8.2+ and Laravel 11+. That is a scheduled upgrade we should sequence deliberately, and it is a cost we would face on our own roadmap regardless.

For engineering: v6.0.0 is a breaking release — PHP 8.2 minimum, Laravel 10 dropped, supported range is Laravel 11/12/13. Budget for: (1) a PHP/Laravel upgrade if we are behind; (2) a migration audit across all drivers we support — the remove_vat_id_column foreign-key ordering fix matters specifically on modern SQLite; (3) regression testing on AccountSchedule aging, because Carbon 3 returns a signed float from diffInDays() and older whole-number assumptions may surface in our own code too. The dev-dependency bump (testbench, PHPUnit 11|12, Collision 8) means our test tooling moves with it. Upside: Laravel 13 readiness ahead of the ecosystem, and a test suite that is now deterministic — the maintainer fixed Faker-related flakiness and zero-value factory data that were producing intermittently failing Trial Balance assertions. That class of bug is exactly what erodes trust in financial tests, and it is now closed. Recommendation: adopt v6 for new work; schedule the upgrade for existing surfaces and treat it as a planned platform milestone rather than an opportunistic bump.