altek/accountant
Altek Accountant adds double-entry bookkeeping to Laravel: define a chart of accounts, record debit and credit journal entries, and query balances per account. It ships with migrations, Eloquent models, and helpers so you can build ledgers directly in your app without an external accounting service.
Architecture fit. altek/accountant is a trait-and-model-event auditing layer for Eloquent. The design pattern is familiar — attach a trait to a model, capture created/updated/deleted/restored events, write an immutable ledger record with the acting user, and keep per-model revision tables that mirror the source schema. That fits cleanly into a conventional Laravel monolith or modular monolith where the domain models are the single write path and "who changed what, when" is a compliance or support requirement. It does not fit event-driven or CQRS architectures where writes bypass Eloquent, and it is not an enterprise audit bus — there is no outbound event stream, no tamper-evident hashing, and no external sink. Treat it as record-level change history with actor attribution, not as a system of record for regulatory audit unless compensating controls are added.
Integration feasibility. Mechanically straightforward: composer require, publish config and migrations, apply the trait to selected models, and generate the corresponding ledger tables. A competent Laravel developer can have a pilot working in under a day. The friction is entirely in the edges: Laravel major-version support, database driver behavior for the mirrored column types, primary-key strategy (auto-increment vs UUID/ULID), soft deletes, and whether actor resolution works when there is no HTTP session. Feasibility is high; durability of that feasibility over the next 18 months is the real question.
Technical risk. This is the dominant concern and it is not close. Zero stars, zero dependents, a GitLab-hosted repository outside the main Composer ecosystem's visibility, and a composite score of 0 mean the package has essentially no community validation. There is no evidence of an active maintainer, no security disclosure process, no release cadence to plan against, and no pool of practitioners who have hit the same edge cases you will. The realistic risk profile is a single-maintainer or already-dormant project. Secondary technical risks: per-model ledger tables cause schema proliferation that grows with your domain model count; the ledger duplicates PII into tables that may fall outside your normal retention and erasure workflows; audit writes ride the same transaction as the business write, so a ledger failure can roll back a legitimate business operation; and Eloquent events are silently bypassed by DB::table() updates, Model::query()->update(), raw SQL, and bulk imports, producing audit gaps that look like tampering. Given the compliance-adjacent purpose, the acceptable risk threshold for adopting this unmodified is low.
Key questions.
Stack fit. Appropriate if we are on Laravel with Eloquent as the sole write path, standard auth guards, and a relational database. It is a poor fit if we run Laravel Octane with long-lived workers (actor state leakage between requests must be verified), if we write through multiple services, or if we need audit data in a warehouse in near real time. The package produces database rows, not events; downstream analytics would need CDC or a polling export.
Migration path. Because audit history cannot be backfilled meaningfully — the ledger only knows what happened after adoption — the migration is really an adoption cutover, not a data migration. Approach: run a two-to-three week spike in a non-production environment against a single high-value domain (e.g. billing or user entitlements); instrument write latency and row growth; verify actor capture in web, queue, and console paths; confirm the ledger tables survive a schema change to the source model without breaking. Critically, wrap access behind our own thin interface (an AuditRecorder port, or at minimum a repository/service that owns ledger reads) so that a later swap to owen-it/laravel-auditing, spatie/laravel-activitylog, or a homegrown solution is a contained change rather than a rewrite.
Compatibility. Verify against our exact matrix: PHP version, Laravel major, MySQL vs PostgreSQL, and JSON/column type support. Check interaction with packages that already hook model events, with soft-delete traits, and with any existing observer-based auditing. Confirm the license permits vendoring the source into our repository if the upstream disappears — plan on that being the default outcome.
Sequencing.
Maintenance. Assume we own it. Budget for a named internal maintainer, a pinned version, and a standing task each Laravel upgrade cycle to validate or patch compatibility. Vendoring the source into our monorepo is the lower-risk posture; it converts an unmaintained external dependency into ordinary internal code with a known owner.
Support. There is no vendor, no SLA, no community, and effectively no Stack Overflow corpus. Every incident is first-principles debugging by our own team. For a compliance-adjacent capability that is a meaningful ongoing cost, and it should be priced into the business case rather than discovered during an audit.
Scaling. Two effects matter. First, write amplification: every audited write becomes at least one additional insert, plus index maintenance, so throughput on hot tables degrades measurably and should be benchmarked before rollout. Second, schema and storage growth: per-model ledger tables multiply migration count and operational surface, while row volume grows monotonically with no built-in pruning. Define an archival boundary (e.g. move ledger rows older than 24 months to cold storage) and a PII retention policy at design time, because retrofitting erasure across N ledger tables is expensive.
Failure modes. Expect: null actor in queued and scheduled work; audit rows missing for bulk operations and raw queries, which read as gaps in a compliance review; ledger insert failure rolling back or, if made non-blocking, silently dropping an audit record; orphaned ledger tables after model refactors; ledger schema drift after source-model column changes; PII exposure in tables that were not in the original data-map; and total loss of upstream fixes if the project is dormant and we never forked.
Ramp-up. Developer ramp-up is genuinely low — a mid-level Laravel engineer is productive in a day, and the concept maps to patterns most teams have seen. Operational and compliance ramp-up is the real cost: security review, data-mapping updates, retention policy, audit-evidence procedures, and an internal ownership commitment. Estimate one to two engineering weeks for the spike and pilot, plus a standing fractional-owner allocation thereafter. The recommendation a TPM should carry into the decision is not "adopt or reject the package" but "adopt the pattern, and treat this specific implementation as a starting point we fork and own" — unless the compatibility spike reveals it aligns with a currently supported Laravel release and a maintainer is verifiably active, in which case a pinned, vendored, allowlisted adoption is defensible.
How can I help you explore Laravel packages today?