Auto-reset when a client edits a flagged invoice

When this article is for you

You flagged an invoice, the client did something, and now you want to know — did the auto-reset actually fire? Will the invoice come back to my queue automatically? What counts as "an edit"? This article walks through the exact cycle, the precise trigger logic, and the edge cases where auto-reset doesn't fire as expected.

For the broader review-queue mechanics, see the review queue explained. For the flag-templates that produce the initial flag, see using flag templates. For where the queue lives in the cockpit, see tax-advisor cockpit.

The cycle, step by step

The flag-to-resolution cycle has five steps. Each step has a clean audit-log entry; the whole cycle is reconstructible after the fact.

Step 1 — You flag

Open the invoice → click Flag → pick a template (or write a custom comment) → Send.

The invoice transitions to status Pending advisor review. Audit log entry: flag.created with your user-ID, the timestamp, the comment text, the template used (if any).

Step 2 — Client is notified

Two notification channels:

• Email to the client's account-owner address from [email protected] with the flag comment + a deep-link to the invoice.
• In-app banner on the client's Documents view: "Your advisor flagged an invoice for review" with a count + link to the queue of flagged invoices.

The notification respects the client's Settings → Notifications preferences. If they've disabled advisor-flag emails, only the in-app banner shows.

Step 3 — Client opens + edits

The client clicks the deep-link → invoice detail page opens. They see:

• A yellow Advisor flagged banner at the top with your comment + your name
• Highlighted field (where applicable) — if you used the "Wrong VAT rate" template, the VAT rate field gets a yellow ring; if "Date is wrong", the date field, etc.
• The full audit history if they expand it (so they can see what you've said about this invoice over time)

They change the flagged field (or any other field) and click Save.

Step 4 — Auto-reset fires

The moment the client saves a field-value change on a flagged invoice, three things happen atomically:

• The invoice's status flips from Pending advisor review to Re-submitted, needs re-review.
• The invoice is pushed to your review queue with a fresh sort-position (top of the queue by default).
• The audit log records field_edited (with the field name + before/after values + the client's user-ID) immediately followed by re_submitted (the status transition).

The push to your queue is real-time — within seconds of the client's save, your queue refreshes with the item visible. The cockpit shows a small "+1" indicator on the Review queue panel.

Step 5 — You re-review

You open the re-submitted invoice from your queue. The yellow Advisor flagged banner is replaced by a green Client edited — re-review banner with a summary of what the client changed.

You either:

• Approve → invoice transitions to Approved, leaves your queue, cycle ends.
• Flag again → new flag overlays the old one (old flag stays in audit history). Cycle repeats from step 1.

The cycle ends when you Approve. There's no automatic "give up after 3 round-trips" rule, but after 3 round-trips the system shows you a warning banner suggesting escalation (see using flag templates for escalation patterns).

What counts as "an edit"

The auto-reset trigger is precise. It only fires on actual field-value changes; not on cosmetic interactions:

Triggers the auto-reset:

• Changing the value of any extracted field — vendor, amount, VAT rate, VAT amount, net, gross, date, due date, category, currency, line items (any line, any field), invoice number, vendor address, VAT ID
• Replacing the original document file (re-upload to the same invoice ID)
• Confirming a previously-blank or low-confidence field that was unset

Does NOT trigger:

• Opening the invoice and just looking at it
• Adding a comment without changing data (comments go to a separate audit thread)
• Re-running OCR (Re-scan) without the new extraction differing from the old
• Marking the invoice with a per-client tag or label
• Opening the document file (Download original doesn't count as an edit)
• Adjusting per-client display preferences (e.g. expanding the line-item view)

The trigger is at the field-write level in the database. Field-write means the value changed; viewing or commenting doesn't write a field value.

Why this design

Without auto-reset, the round-trip would be: you flag → client edits → client forgets to tell you → you re-check yourself periodically (or it sits forever in some "waiting" limbo). That's lossy and slow.

Auto-reset closes the loop without manual coordination. It also encodes the right mental model: a flagged invoice is "pending YOU" (the advisor), not "pending the client". You flagged, client acted, now it's your turn again. The status name Pending advisor review reflects this — the invoice is technically pending you, not them.

A side benefit: the audit trail is clean. Every flag-resolution cycle has a structured log (flag.created, field_edited, re_submitted, approved OR flag.created again for re-flag). Compliance audits can reconstruct who-said-what-when without spelunking through chat threads or emails.

What the client sees during the cycle

The client's experience matters for your client's day-to-day. Here's what they see at each phase:

• After your flag: yellow Advisor flagged banner with your comment text + your name. The flagged field (if your template targets a specific one) gets a visual highlight. The client knows exactly what to fix.
• While they're editing: the banner stays yellow. The field they're editing shows the usual edit-state (text input, etc.). They can save anytime.
• After their edit + save: banner changes to Re-submitted — your advisor will re-review. They don't need to ping you; the system pushes the invoice to your queue automatically. They can keep working on other invoices.
• After you Approve: banner disappears entirely. Invoice is final.
• After you re-flag (cycle restarts): new yellow banner appears, possibly with a different comment if you changed the template. The client sees the new comment + a small "3rd round" indicator if this is the 3rd flag on the same invoice.

This is all designed so the client never feels lost. They always know whose ball it is.

Audit log diff

The most useful debug surface when auto-reset doesn't behave as expected is the per-invoice audit log. Open any invoice → Audit log tab. You see a chronological list with:

• Timestamp (with timezone)
• Actor (user-ID + role — advisor:Tom Klein or client:Acme GmbH owner)
• Action (flag.created, field_edited, re_submitted, approved, etc.)
• Detail (the comment text, the before/after field values, the IP address)

If a client claims they edited but the auto-reset didn't fire, the audit log tells the truth — did the field_edited event happen? If yes, the auto-reset should have fired (if it didn't, that's a bug worth reporting). If no, the client opened-but-didn't-save, or edited a non-trigger field.

Edge cases

Client edited a different field than I flagged. Still triggers auto-reset. The invoice comes back to your queue. The status banner shows Client edited with a summary like "Client changed VAT rate (19% → 7%) and amount (€100 → €105)" — even though you flagged the date. Open and read the changelog tab to see what they actually changed; sometimes they correct a different field that was also wrong.

Client edited the invoice 5 times before I re-reviewed. Counts as 5 re-submissions in the audit log. The queue shows only the latest state when you open the invoice, but the audit trail keeps every step. If the cumulative diff is non-trivial (e.g. client cycled the vendor name several times), the audit log helps you understand the path.

I want to flag a re-submitted invoice for the same reason as before. Just flag again with a new template (or the same one). The new flag overlays the old in the active state, but the old flag stays in the audit history. No need to delete the old flag.

Auto-reset isn't triggering even though the client says they edited. Check the invoice's audit log:

1. Did field_edited happen? If yes → the auto-reset should have fired (refresh your queue; if still missing, write to support with the invoice-ID).
2. If no → the client opened the invoice but never saved a change. Common confusion ("I clicked the field but didn't type" — no edit). Ask them to make the edit explicitly and save.
3. If the edit was on a non-trigger field (rare) → see what counts as an edit.

Multiple advisors on the same client — who gets the re-submitted invoice? All advisors invited to that client see the re-submitted invoice in their respective queues. First-action-wins: whoever approves or re-flags first removes the item from the other advisors' queues. The audit log records who acted. For coordination, the convention "one lead advisor per client" minimises double-handling.

Client says they fixed but the invoice came back to their queue with my old comment. This happens when the client edited and saved, but the auto-reset hadn't pushed to your queue yet (network lag, very rare). They might have refreshed too quickly and saw a stale state. Wait a few seconds and refresh — should normalise. If it persists, the auto-reset job might have failed (write to support).

Client edited then immediately re-edited (within the same minute). Two field_edited events, but the auto-reset coalesces — only one push to your queue, the most recent. The audit log keeps both events.

I flagged but the client edited before my flag email arrived. Email delivery is async; the flag is created the moment you click Send, the email is sent on best-effort. If the client happens to be on the invoice page at that moment and edits before the email arrives, the auto-reset still fires correctly — the trigger is the client's save event vs the invoice's flag status, not the email.

Client deleted the invoice instead of editing. Deletion is destructive but allowed. The audit log records invoice_deleted by the client. The flag becomes orphaned (no invoice to re-submit). For your records, the audit history persists; for the client, the invoice is gone (subject to the 30-day soft-delete grace period if the client undeletes).

Related

• The review queue, explained — where re-submitted invoices land
• Using flag templates — the flag-side of the cycle
• Tax-advisor cockpit — the broader navigation context