Filament Money Laravel Package

Product Decisions This Supports

• Admin surface for anything priced. Catalog/price editing, invoice and order line items, refunds, subscription plan pricing, payout review — if the roadmap includes a Filament admin where finance or ops staff touch money, this replaces hand-rolled currency inputs and sprintf formatting scattered across resources.
• Build vs buy on money input. The decision it unblocks is standardizing capture and display of monetary values in admin: one component, one convention, instead of each engineer inventing minor-unit handling. Buying is near-zero cost; building is a recurring tax.
• Multi-currency / international expansion. A currency-aware field lets you validate that admin screens can display and edit amounts per currency before committing engineering to a full multi-currency data model — a cheap way to de-risk an i18n/pricing roadmap item.
• Data-integrity risk reduction. Money-as-float defects in invoices, refunds, and reports are expensive and public. Adopting a money abstraction early (integer minor units + currency, formatting in the presentation layer) is a risk decision, not just a UI convenience.
• Internal ops tooling and finance workflows. Supports roadmap items like promotions, credits, manual adjustments, and price overrides with guardrails rather than raw numeric fields.
• Scope discipline. Choosing it is also a decision to keep money math in a dedicated library and money formatting at the edge — a useful boundary to state explicitly when scoping finance-adjacent features.

When to Consider This Package

Consider it when:

• Your stack is Laravel + Filament and you already have (or plan) admin resources with monetary attributes.
• You want consistent currency parsing/formatting across many resources without each developer reinventing it.
• You need multi-currency input and display rather than a single hardcoded symbol.
• You're early enough that swapping the field later is cheap and the blast radius is small.
• The team prefers small, single-purpose, MIT-licensed packages over a heavyweight admin suite.

Look elsewhere (or proceed with conditions) when:

• You are not on Filament — most of the value is the field integration; a standalone money library (brick/money, moneyphp/money) covers storage and arithmetic.
• You need accounting-grade capability: double-entry ledgers, tax engines, FX rate feeds, jurisdiction-specific rounding. This is a UI convenience, not a finance engine.
• Money must be rendered outside admin (PDFs, emails, public APIs, mobile) — you'll need a shared formatting layer regardless; don't let a form field define your money model.
• The surface is revenue-critical and the package is tiny — 10 stars, 0 dependents, single maintainer. Require a code audit, version pinning, and a fork/vendor contingency before adoption.
• Your money semantics are unusual — crypto precision, six-decimal unit prices, per-unit vs. line-total ambiguity. Verify fit before committing.

How to Pitch It (Stakeholders)

Executives: A low-cost, MIT-licensed component that shortens delivery of billing and pricing admin screens and removes a class of bugs — rounding errors and currency display mistakes — that turn into wrong invoices and support tickets. No license spend, small integration effort, contained risk: worst case it is replaced by a few hundred lines of in-house code. It also gives us a cheap way to prove out multi-currency admin before funding a larger internationalization effort.

Engineering: A thin Filament form field and table column wrapping a money value object — integer minor units plus currency in the model, formatting pushed to the UI. It is small enough to read end to end and to fork if needed. Adoption recommendation: pin the version, add tests for the edge cases that bite (zero-decimal currencies like JPY, negatives and refunds, very large amounts), and document the money convention in the codebase so the plugin stays a swappable presentation detail rather than a dependency of our data model.

Risk framing: Single-maintainer package with a small community. Mitigate with a one-time code audit, pinned versions, and a documented fallback to an in-house or forked implementation. Keep money arithmetic behind our own value-object boundary so the Filament plugin can be replaced without touching business logic.