Approval follows persistence
Estimates and purchase orders now save dirty content before approval; public approval is tied to the intended saved revision and recipient.
- Save before state change
- Material revision binding
- Explicit failure state
Product updates
What changed, why it matters and what the entry does not prove
A dated, documentation-derived view of recent Invoice Crowd product work. It separates implemented local behavior from production deployment status and keeps important limitations in the same entry.
- Documentation-derived
- Last reviewed August 7, 2026
- Not a deployment confirmation
Last updated:
Recent direction
Preserve the record, require evidence, keep the next action clear
The latest documented work clusters around document integrity, retry-safe financial operations and collaboration controls.
Document integrity
Recent editor work binds approval to the saved document state.
The boundary remains visible
A failed validation or save leaves the document unapproved rather than inferring that the attempted state change succeeded.
- No partial approval
- Retry from saved state
- Historical facts preserved
Operational safety
Expense and payment work now relies on durable, server-owned evidence.
Retries do not become duplicate writes
Expense idempotency and provider-side payment verification separate a retry or browser return from a confirmed financial mutation.
- Payload-bound request key
- Provider evidence
- Exact amount and currency
Uncertainty stays unresolved
Ambiguous provider responses and failed saves retain a pending or failed state instead of manufacturing success.
- Fail closed
- Stable operation identity
- Review before retry
Collaboration clarity
Notifications and permission gates make context and next actions easier to understand.
Richer context, narrower authority
Notifications carry business and record context while team authorization denies unknown modules and preserves owner-only surfaces.
- Business identity snapshot
- Safe application action
- Deny-by-default team gate
Preferences stay deliberate
Bell and Email choices are explicit, and a brief hover or failed read request does not silently clear an unread item.
- All and Unread views
- 650 ms deliberate hover
- Failed writes preserve state
Dated change notes
Recent locally verified product work
These entries summarize the current application documentation. They do not claim that a specific production environment has deployed the corresponding code.
-
August 6, 2026: Recurring editor dark-mode consistency
The Vue invoice-family editor now gives the Make Recurring schedule groups, controls and status states the same scoped dark-mode treatment as the shared editor rail. Light mode remains unchanged.
-
August 3, 2026: Save-before-approval document integrity
Dirty estimates and purchase orders save successfully before internal approval. Public estimate approval binds to the saved material revision and intended recipient, preventing a stale approval from silently covering changed content.
-
July 26, 2026: Retry-safe expense saves and currency precision
Standalone expense saves now use a form-scoped state machine and idempotency key so rapid clicks and safe retries cannot create a second accounting write. Converted amounts follow the target currency's ISO decimal precision.
-
July 21, 2026: Bounded AI expense attachments
The AI assistant added a reviewed expense path for temporary CSV/XLS/XLSX files and JPEG/PNG receipts. The result is staged as one itemized confirmation card; general importer handoffs and assistant payment recording remain outside the shipped boundary.
-
July 17, 2026: Actionable notification center
The header bell and full notification center now share event-specific presentation, business context and safe application-relative actions, with All and Unread views plus explicit Bell and Email preferences.
-
July 16, 2026: Provider-verified payment settlement
Active one-time payment paths require provider evidence and exact account, invoice allocation, amount, currency and successful-state checks. PhonePe remains retired instead of accepting browser or callback fields as settlement truth.
-
July 12, 2026: Accounting and team-control hardening
Forward accounting writes gained additional balanced and currency-aware controls, while team authorization moved to a deny-by-default controller map with owner-only billing, settings and profile surfaces.
-
How to read this page
Entries summarize the current local application documentation and source contracts.
-
Deployment is a separate event
A documented local change is not presented as confirmation that a production tenant has deployed it.
-
Preservation rule
Changes affecting accounting, documents, users or uploads must preserve existing records and access.
-
Verification date
The public changelog content was assembled and checked on August 7, 2026.
-
Release evidence
Production status requires deployment and recurrence evidence outside this marketing site.
Questions
Reading the changelog, answered
Is this a production deployment log?
No. It is derived from the currently reviewed local application documentation and code contracts. A local implemented or verified date does not, by itself, prove that every production environment has deployed the change.
Why are there no semantic version numbers?
The supplied product documentation records dated feature and hardening work rather than a reliable public semantic-version sequence. This page does not manufacture version labels.
Does every entry describe a new customer-facing feature?
No. Some entries are integrity, authorization or retry-safety improvements that make an existing workflow more dependable without adding a new menu item.
Are known limitations removed from the notes?
No. The AI attachment entry keeps broader importer and payment recording work outside the shipped boundary, and the payment entry keeps PhonePe retired.
Can a changelog entry prove my account has the change?
No. Verify the relevant screen and behavior in the environment you use. For a production issue, confirm the deployed commit and check that the failure does not recur after deployment.
How are records protected during changes?
The documented engineering policy preserves user, tenant, accounting, document and upload data. Financial changes favor additive records, explicit retirement or controlled reversal over destructive historical rewrites.
Verify the current workflow with representative data
Use the detailed feature guide, test the behavior in your environment, and preserve a fallback before adopting a newly changed financial or document process.
- Boundaries remain visible
- No invented release versions
- Data preservation first