A SaaS application that serves businesses across regions must handle money and time as business data, not merely display preferences. A currency symbol alone does not say what an amount means, and a timestamp without a time zone can turn a deadline into the wrong day. Clear storage rules and explicit conversion boundaries prevent subtle billing, scheduling, and reporting errors.
Money needs an amount and a currency
Store the currency alongside each monetary value. Use a decimal-safe representation or integer minor units according to the domain; ordinary floating-point arithmetic can produce rounding surprises. Do not assume every currency has two minor units. A displayed price should be formatted for the viewer's locale, but its underlying currency should remain the one agreed in the transaction. Converting a price to another currency is a separate business operation that needs a rate source, timestamp, rounding rule, and clear disclosure. Formatting a number with a different symbol is not conversion.
Keep accounting decisions explicit
Taxes, discounts, refunds, and exchange-rate differences require defined rules. Decide when amounts are rounded and whether calculations happen per line or on totals. Record the currency and rate used at the time of a transaction so later reports do not change when live rates move. A tenant may have a default currency, while individual invoices or products use another. Reports that combine currencies should either show separate totals or apply an explicit conversion basis. The API should return render-ready labels and totals so the client does not recreate financial logic.
Distinguish instants from local schedules
An instant, such as “payment received at this moment,” can be stored as a UTC timestamp and displayed in a user's time zone. A recurring local schedule, such as “run at 9:00 every Monday in Tehran,” needs a named time zone and recurrence rule. Converting one occurrence to UTC and repeating that UTC hour can shift the local time when daylight-saving rules change. Store the intent and calculate future occurrences with a maintained time-zone database. For deadlines expressed as a local date, avoid inventing a midnight instant unless the business rule requires one.
Resolve time-zone preferences
A user, tenant, and event may each have a relevant time zone. An appointment belongs in its venue's time zone; an audit log may be displayed in the viewer's time zone; a tenant report may use the business's reporting zone. State the choice in the product and API contract. Show a time-zone abbreviation or offset where ambiguity matters, especially in invitations and cross-region collaboration. Test transitions where local times repeat or do not exist. A time picker should handle those cases deliberately rather than silently choosing an unexpected instant.
Format for the audience
Locale-aware libraries can format dates, numbers, and currencies, but the application must select the correct locale and business value first. A person can prefer one language while working in another region, so do not derive currency from language alone. Consider calendars and numeral systems where the target market needs them. In exports and APIs intended for machines, use unambiguous structured values instead of localized display strings. In customer-facing views, label amounts and dates clearly enough that users can verify what they are approving.
Verify with realistic cases
Test zero-decimal and non-default currencies, partial refunds, month-end billing, users traveling between zones, and recurring events across clock changes. Include cases where a tenant's reporting zone differs from a user's display zone. Reconcile totals after formatting to ensure rounding has not changed the underlying accounting result. For SMB software, these checks matter because a small mistake on an invoice or appointment can damage trust quickly. A modest, explicit money-and-time model is more dependable than a collection of special cases added after customers report errors.