Laravel Accounting Laravel Package

Technical Evaluation

Architecture fit. aseven-team/laravel-accounting is a Filament panel plugin rather than a headless accounting domain library: it ships TransactionResource, report pages, and starting-balance views as first-class Filament artefacts. That makes it a strong fit only if our admin surface is already Filament-based and we are content to inherit its resource/page conventions (routing, policies, navigation, form schemas). If we need accounting logic exposed via API, jobs, or a non-Filament UI, we would be consuming the underlying models directly and inheriting an integration surface the package does not document as stable.

Integration feasibility. v2.0.0-alpha widens the compatibility window substantially — PHP 8.2+, Laravel 11.28+/12/13, Filament 4 or 5 (Livewire 4). Installing is a single Composer require with an explicit @alpha stability flag, which is also the clearest signal that this is not a default-branch dependency. Feasibility is high on a greenfield Filament 4/5 panel; it is materially lower on any panel with customisations layered on the package's resources or pages.

Technical risk.

• Pre-release API churn. The release notes state plainly that the API may change before v2.0.0. Any code we write against it — resource overrides, page extensions, custom report wiring — is throwaway work to a non-zero probability.
• Filament v3 is hard-dropped. There is no dual-support path. Teams on v3 must remain on ^1.6.2. This is a fork in the road, not a deprecation runway.
• Override breakage is the dominant cost. Forms moved to Filament's Schema API. Any subclassed resource or page must be rewritten, and the package does not enumerate which extension points survive.
• Transitive dependency removal. awcodes/filament-table-repeater is gone in favour of Filament's built-in table repeater. Where that package was pulled in solely by us, removal is free; where other plugins or our own code reference it, we get a version-resolution conflict at install time.
• Security posture. The release carries the fixes from v1.6.2 (GHSA-rm2q-6g93-p4xg): report pages now require TransactionResource::canViewAny(), and submitted account IDs are validated. The authorization gap is the more serious of the two — pre-fix, report pages were reachable without the resource's view permission. Any deployment on an earlier v1 line is exposed today, independent of the v2 decision.
• Correctness fixes bundled with the upgrade. Starting balances and report filters failing to persist state on Filament v4+, plus replacement of Blade components Filament v4 removed, are genuine defects. They reduce the "just stay on v1" argument for anyone already on Filament 4.

Key questions.

1. What is the realistic GA date for v2.0.0, and is there a published extension-point/stability contract for Schema-based forms?
2. What is the support window for the v1.6.x line — security-only, and until when?
3. Are we on Filament v3 anywhere in production, and if so, what is the panel upgrade cost to v4/v5 independent of this package?
4. Does the advisory affect our current installs, and has 1.6.2 been deployed where v2 is not yet viable?
5. Is multi-tenancy, multi-currency, or double-entry integrity a requirement, and does the package document its data model and migration story?
6. Is awcodes/filament-table-repeater referenced anywhere outside this package's dependency tree?

Integration Approach

Stack fit. The package assumes a conventional Laravel + Filament panel: service-provider registration, policy-driven authorization, Livewire-rendered pages. We should treat Filament version as the primary axis of the decision, not the package version. Filament 4/5 + Laravel 11.28+/12/13 → v2 alpha is the only supported path. Filament 3 → v1.6.2 is the only supported path, full stop.

Migration path. There is no in-place upgrade from v1 to v2; it is a re-platform. The practical sequence:

1. Remediate first, independent of v2. Confirm every environment is on ^1.6.2 or carries the advisory fixes. This is a security task, not an upgrade task, and should not wait on the alpha.
2. Inventory customisations. Enumerate every subclass, override, published view, and navigation/policy hook we have against the package's resources and pages. This inventory is the true cost estimate for v2.
3. Resolve the repeater dependency. Determine whether awcodes/filament-table-repeater appears in our composer.json directly or via other plugins before attempting the require.
4. Upgrade the panel, then the package. Filament v3→v4/v5 is the larger, riskier move; do not compound it with a package re-platform in the same change.
5. Pilot in a non-production panel with the @alpha constraint pinned to an exact version, not a floating range.

Compatibility. Pin to an exact alpha build (2.0.0-alpha + commit hash) rather than ^2.0@alpha; floating pre-release constraints will silently move us onto breaking builds. Verify PHP 8.2+ and Laravel 11.28+ at the platform level — a Laravel 11.0–11.27 host will fail resolution, which at least fails loudly.

Sequencing. Security remediation (now) → customisation inventory (now, parallel) → Filament panel upgrade (scheduled) → package v2 evaluation (gated on inventory and pilot) → production adoption (gated on v2 GA or a documented decision to run pinned alpha in a bounded blast radius).

Operational Impact

Maintenance. Two supported tracks exist and we may end up on both simultaneously if any panel remains on Filament v3. That means two dependency constraints, two sets of override code, and two upgrade conversations. Budget for this as ongoing overhead, not a one-time migration cost. The Schema API move also implies our override code is coupled to a Filament-internal pattern that is still settling across v4→v5.

Support. Pre-release software from a single-maintainer package carries no support guarantee. Our escalation path for a production defect is a GitHub issue. For an accounting surface — transactions, starting balances, financial reports — that is a material supportability gap that needs an owner and an accepted-risk sign-off, not just an engineering decision.

Scaling. Accounting datasets grow monotonically; transactions, starting balances, and report queries accumulate rows forever and are never pruned. Report pages are the likely performance cliff, and the package's indexing and pagination behaviour is undocumented here. Any adoption plan should include a data-volume test at realistic multi-year scale before committing. Note also that report filters and starting-balance state persistence are only just fixed in this release — verify that behaviour holds under our expected filter combinations.

Failure modes.

• Silent authorization regression if a future refactor bypasses or weakens the canViewAny() gate the advisory introduced — this deserves a test in our suite, not just a dependency bump.
• Pre-release drift: an unpinned alpha constraint advancing mid-sprint and breaking builds.
• Dependency conflict on the repeater removal, surfacing as an unresolvable composer require rather than a runtime failure — cheaper to discover, but blocking.
• Broken overrides after a Filament patch release, since Schema-based forms are the newest and least-settled part of the surface.
• Financial data misstatement from incorrect starting-balance or filter state — the class of bug this release fixes — with no package-level audit trail to detect it after the fact.

Ramp-up. Low conceptual ramp: it is a Filament plugin and behaves like one. The real ramp is in understanding the package's data model and migration behaviour well enough to trust it with financial records, which the release notes do not address. Plan for a spike by one engineer covering: schema and migration review, a data-volume report test, and a written inventory of extension points we depend on. That spike output is the input to the go/no-go decision — and the recommendation it supports today is narrow: remediate to v1.6.2 immediately, pilot v2 alpha only on Filament 4/5 with an exact pin, and defer production commitment until v2.0.0 GA or a documented stabilisation commitment from the maintainer.