Business profile

What happens if I change my display currency after I've already made sales?

The setting flips immediately, and from the moment of save every NEW sale, invoice, refund, and receipt renders in the new currency code. But historical sale and invoice rows already in the database aren't stamped with the currency-at-time-of-sale — Nexpura stores totals as raw decimals and reads your tenant's current currency to pick the locale and code at render time.

Practical result: if you switch AUD → USD with existing AUD sales in your history, every historical total retroactively displays as USD with the same numerical value. $50,000 AUD becomes $50,000 USD on screen — not a real conversion, just a relabel. If your reporting downstream of Nexpura depends on old-currency labels (e.g. you've already booked the year-to-date totals in AUD into Xero), the relabel is silent. The system doesn't warn at save time today; the warning lives in the walkthrough step above.

Two safe approaches: change the currency before you start trading on Nexpura, OR treat a change as a one-way operation — export your historical sales to CSV first (so you have the old-currency reporting snapshot preserved outside the system) and then flip the field, knowing the on-screen display relabels from that point.

Why are there two business-profile-like surfaces — a dedicated /settings/business-profile page and a Business Profile tab on /settings?

Both write to the same tenants row — they're alternate UIs for the same data. The dedicated route is the canonical post-migration shape (page-layer owner / manager gate, async data-load pattern, focused on one section). The combined surface predates the extraction and still groups Business Profile, Tax & Currency, Banking, Account, and Security under one client SPA — useful when you're configuring several at once during onboarding.

No content drift between the two — saves from either UI are immediately reflected on the other on next load. The per-tab migration is continuing post-engagement; eventually Tax & Currency, Banking, and Account will each move to their own dedicated routes alongside the business profile one.

Why are tax / banking / business identity gated to owner and manager only, not staff?

These surfaces configure tenant-wide identity that prints on every invoice your store issues to a customer. Banking details specifically — the BSB and account number — are where customer payments land on direct deposit; a rogue staffer who could swap them for their own would be redirecting your revenue. Tax configuration sets the rate applied to every sale; changing it incorrectly leaves you under- or over-charging across hundreds of transactions before anyone notices. Business name changes propagate to every receipt, quote, and customer email going forward — a destabilising surface to delegate.

The permission matrix (configurable per role at /settings/team/permissions) doesn't include a “manage business identity” key for the same reason — owner + manager is the right boundary, and it lives at the role layer rather than as a delegate-able permission. The team-and-roles page covers this in more depth.

I'm migrating from another POS. How do I make my first Nexpura invoice continue my existing invoice numbering?

Open /settings/numbering, find the Invoice Number row, and set the sequence to your LAST old-system invoice number. The “Next document will be” preview will show one higher. Save. Your first Nexpura invoice then issues at that number, and continues incrementing.

Same approach works for SALE-, REP-, JOB-, and QUO- — each row has its own counter and Save button, configure them independently. Do this BEFORE you start issuing real Nexpura invoices; reordering afterward leaves gaps or duplicates that auditors will flag.

Can I configure different currency or tax rates per location?

No — currency, tax name, and tax rate are tenant-wide settings, not per-location. Every location operates in your single tenant currency and tax jurisdiction. If you operate across two countries with different tax rules, two separate Nexpura tenants is the current shape. Talk to us if multi-jurisdiction support inside one tenant is load-bearing for your store — it's on the roadmap conversation, not on the immediate ship list.

What does “tax inclusive” actually change?

Tax-inclusive ON means your stored retail prices already include tax — a $110 necklace with 10% GST tax-inclusive splits into $100 ex-tax + $10 GST on the invoice. The customer sees $110 on the price tag and pays $110; the GST line is calculated backward.

Tax-inclusive OFF means your stored retail prices are pre-tax — the same $100 ex-tax necklace adds $10 GST at checkout for a $110 total. The customer sees $100 on the tag and pays $110.

Australian retail almost always uses tax-inclusive (the price tag is the price they pay); B2B wholesaling almost always uses tax-exclusive (quotes and invoices show + GST). Pick the one that matches how you display prices to customers.

I changed the display currency and now my historical sales show the new currency code

Symptom: you switched AUD → USD (or any other pair) and the dashboard, sales list, and existing invoice PDFs now show $ values labelled with the new code even though they were recorded as the old one. Cause: expected — Nexpura reads the tenant's current currency setting to pick the code and locale at render time. Historical totals aren't stamped with the currency they were originally booked in, and the relabel applies retroactively. Documented in the walkthrough step above and the Common questions entry. Fix:if the switch was deliberate, no fix needed — the new currency label is what you wanted going forward. If the switch was a mistake, flip the field back to the original currency on the same Tax & Currency tab; historical totals revert to their correct label since the numerical amounts were never changed. If you need the old-currency reporting preserved alongside the new, export sales to CSV with the correct currency label BEFORE switching.

Save on the Business Profile form returns “Only owner or manager can edit business profile”

Symptom: the form submission returns the permission-denied error inline. Cause: you're signed in as a staff or technician role. Business profile mutations are gated to owner + manager at both the page layer (which usually redirects you to /dashboard before the form renders) and the server-action layer (defence-in-depth). Fix: ask an owner or manager to flip the field, or ask the owner to elevate your role at /settings/team. Team-and-roles documents the role boundaries in detail.

I set the invoice sequence to 100 but the next invoice still issued at the old number

Symptom: you opened /settings/numbering, changed an invoice sequence to 100, but the next invoice came out at the old number (e.g. INV-0023 instead of INV-0101). Cause:the Save button on the numbering rows is per-row — each row has its own Save button next to its input. The change doesn't persist until you click the row Save; the parent page has no global Save. Easy miss if you're used to the combined-form Save shape elsewhere in settings. Fix:open /settings/numbering again, set the value, click the Save button on that specific row, wait for the “✓ Saved” badge. Then verify the “Next document will be” preview shows the expected number. Issue a fresh invoice to confirm.

Invoice PDF shows the wrong tax rate even though I just updated it

Symptom: you changed the tax rate on /settings, saved, but opening an existing invoice still shows the old rate. Cause: expected — existing invoices are stored with their tax breakdown at the time they were issued. Re-opening an old invoice doesn't re-apply the current tax rate; the invoice is a record of what the customer was charged. Fix: no fix for existing invoices — they correctly reflect the tax rate at time of issue. The new rate applies to every invoice issued after the save. To verify, create a fresh invoice at /invoices/new and confirm the tax line uses the new rate.

The bank account number disappeared from the form after saving — did I lose it?

Symptom: you entered banking details, saved, but on next load the BSB and account fields look empty or partially filled. Cause: banking details are encrypted at rest. The decryption path runs in the server action when the page loads, so the value should re-appear after a full page refresh. If it doesn't, the decryption failed (rare — usually a key-rotation mismatch) and the value did persist encrypted, just isn't being unwrapped for display. Fix:hard refresh the page first (Cmd+Shift+R or Ctrl+Shift+R). If the value still doesn't surface, contact support with the affected tenant ID — the encryption key needs verifying server-side. In the meantime, re-saving the value with the correct BSB / account will overwrite the stored ciphertext with a fresh one bound to the current key, which usually recovers the display.