Laravel Money Laravel Package

Product Decisions This Supports

• Roadmap acceleration for financial and commerce features: Money::sum(), min(), max() and the sumMoney() Collection macro remove bespoke aggregation logic from carts, order totals, invoice subtotals, payout summaries and reporting dashboards. Teams can ship totals, best/worst price views and “sum by currency/key” screens without inventing internal money utilities.
• Tax and discount modelling: Money::percentage() gives product and engineering a shared, explicit primitive for percentage-based calculations (VAT, sales tax, promo discounts), reducing the risk of ad-hoc float math spreading across pricing, checkout and invoicing.
• Build vs buy: This release strengthens the case for adopting a maintained money package rather than building in-house value objects. Aggregation and percentage helpers are exactly where homegrown implementations tend to accumulate rounding, currency-mixing and empty-collection edge cases.
• Use cases to prioritise: multi-line carts and baskets, invoice and credit-note totals, expense and reimbursement summaries, sales/commission reporting, subscription proration, and any dashboard showing “total by currency” or “min/max/average transaction value”.
• Product guardrails: the null-on-empty sumMoney() behaviour and iterable-based APIs make empty-state handling a product decision rather than an exception path, which is useful for zero-state dashboards and new-account experiences.
• Scope signal: the release is additive and focused on computation, not FX conversion, storage or ledger semantics. It supports incremental financial feature delivery but does not by itself justify a full accounting or billing platform build.

When to Consider This Package

Consider adoption when:

• The product performs money arithmetic across collections — carts, invoices, reports, payouts, refunds — and the team wants consistent rounding and currency handling.
• You are on Laravel/PHP and want a Collection-native ergonomic API (sumMoney(), optional key-based aggregation) rather than hand-rolled reducers.
• You need percentage-based pricing logic (tax, discounts, fees) with an explicit money API that is easy to test and review.
• You want to reduce bespoke financial utility code and standardise on a package with an active release cadence.
• Empty collections and mixed-currency inputs need predictable, documented behaviour that product and QA can reason about.

Look elsewhere or supplement when:

• You need multi-currency FX conversion, rate sourcing or historical revaluation — this release covers aggregation, not exchange.
• You require double-entry ledgers, reconciliation, audit trails or regulatory accounting controls; a money value object is a primitive, not a ledger.
• You need persistent decimal storage guarantees across the database and reporting stack — pair this with explicit schema and casting decisions.
• Your workload is high-volume or high-precision (e.g. crypto, metered billing at extreme scale) and requires numeric types beyond the package’s representation.
• You are not on Laravel/PHP or cannot take a dependency on the framework’s Collection macros.
• The team cannot adopt consistent rounding and allocation conventions; the package helps, but policy must still be set.

How to Pitch It (Stakeholders)

For executives: This release lets us deliver money-related features faster and with less financial risk. Totals, tax and discount calculations, and “sum by currency” reporting can be built on a maintained package instead of custom code, reducing defect exposure in checkout, invoicing and dashboards. It is an additive, low-migration-cost upgrade that improves time-to-market for revenue-adjacent roadmap items without committing us to a larger finance platform.

For engineering: v1.2.0 adds Money::sum(), min(), max() over iterables, Money::percentage() for tax/discount calculations, and a sumMoney() Collection macro with optional key-based aggregation and null-on-empty semantics. This is additive and should be a straightforward dependency bump. It replaces common hand-written reducers and percentage math, giving us one tested implementation for rounding, currency consistency and empty-collection handling. Engineering should still define rounding policy, validate currency-mixing behaviour in domain tests, and confirm database decimal precision and casting around persisted amounts.

Recommendation: Adopt v1.2.0 for financial aggregation and percentage calculations where the product already uses Laravel Collections. Treat it as a computation primitive, not a replacement for FX, ledger or accounting controls, and gate adoption on a short spike covering rounding policy, mixed-currency inputs and empty-state UX.