> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Working the review inbox
> Most of what a reviewer does is not approving. Reject, send back and revise: three moves that are not interchangeable.
# Working the review inbox
The routes, UI states, and controls on this page are verified in the pinned source, but the review queue has not been exercised end to end for this documentation cut.
Treat this as the source contract, not proof of a completed production review.
Most of what a reviewer does is not approving.
It is deciding that something is not right yet, and putting it back on the correct track without letting a wrong number near the ledger.
There are three moves, and they are not interchangeable.
| Move | Use it when | What actually happens | Reversible? |
| ----------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------- |
| **Send back** | the document is genuine but the agent read it badly | the row goes back to the agent for another extraction pass. It stays in the queue, the resubmit count goes up, and you become the reviewer | yes, it comes back |
| **Reject** | the document should not be in the books at all: a test, a duplicate, a superseded version | terminal. The row moves to Rejected, your reason is recorded, and nothing is posted | no. Compose or upload again |
| **Revise** (Typewriter) | the document itself is wrong: wrong amount, wrong supplier | creates the next version. v1 is marked superseded; v2 needs its own approval and its own submit | both versions stay on file forever |
**Nothing you do here can reach the ledger.**
Reject, send back and revise all happen before the second gate.
None of them writes a journal entry, and none of them can un-write one.
Once an entry is posted the only correction is a reversing entry.
## The review tabs
| Tab | Meaning | Is anything in the ledger? |
| -------------------- | --------------------------------------------------------------------------------------- | -------------------------------------- |
| **Needs review** | waiting on a human at the intake gate. Includes *received* and *ready to review* | No |
| **Flagged** | the Clerk had a specific doubt and named it. Still needs the intake gate | No |
| **Awaiting posting** | intake approved; the Bookkeeper has drafted an entry and is waiting for a second person | **No.** This is the one people misread |
| **Posted** | both gates cleared. An entry number exists | Yes |
| **Rejected** | terminal. The reason is recorded | No |
| **All** | everything, any status | - |
## Reject, the terminal one
**Reject** opens a confirmation with a free-text reason.
The reason is optional to the form and essential in practice: it is the only explanation anyone will ever see for why this document never reached the books.
```http theme={null}
POST /intake/{intake_id}/reject
X-WorthState-Org-Id:
Content-Type: application/json
{ "reason": "superseded by v2" }
```
**Read the rejected row carefully.**
Your rejection reason is stored as a flag, so a rejected row still displays "1 FLAG TO RESOLVE" with
your own sentence under it, and still shows a count in the FLAGS column.
There is nothing left to resolve. The row is terminal.
Read the green line at the bottom - "Rejected by … - nothing was posted" - not the flag count.
A **rejection** is subject to only half the separation-of-duties rule.
Refusing a document writes nothing to the ledger, so it is gated only on the refusal being
attributable to a named user, not on three distinct people standing behind the record.
Applying the full rule to rejections used to strand documents: a row whose submitter was still a
placeholder could not be posted, could not be rejected, and could not be resubmitted.
It sat active forever and showed up in the Auditor's reconciliation as a document with no journal
entry.
## Send back, and the one row it does not apply to
**Send back** applies only to rows the Clerk actually **flagged**. That is a server rule, and it is an exact equality rather than a range.
On a row at *ready to review* - which is exactly what a Typewriter-composed document lands as, because a schema-built document has nothing to be unsure about - there is nothing to send back to, so the control renders **disabled with the reason** rather than as a button that fails.
The server's own refusal, if the rule is reached another way, is:
> resubmit applies only to a flagged row (this row is 'pending')
**What to do instead.**
A Typewriter document has no agent extraction to redo, so there is nothing to send back **to**.
If it is wrong: **Reject** the queue row, then **Revise** the document in the Typewriter and submit
the new version.
**Approve and Reject** follow the same principle from the other side: a row with an **unrecognised** status still offers them, because the backend can add statuses and a silently un-reviewable row would strand a document.
Send back never gets that benefit, because its server rule is an exact match.
A control this product cannot honour is shown as a **rule**, not as a button that fails.
### On a flagged row the source contract reruns the agent
Type what you want fixed, confirm, and the row is handed back to the agent.
Over the API, a resubmit takes a **patch of fields** that is merged into the row's payload and re-validated.
The row then routes on the result: clean goes to *pending* and is ready to approve, still-flagged stays *flagged* with the remaining issues named.
```http theme={null}
POST /intake/{intake_id}/resubmit
X-WorthState-Org-Id:
Content-Type: application/json
{ "patch": { "vat_amount": 100000 } }
```
```json theme={null}
200 OK
{
"id": "",
"status": "pending",
"issues": [],
"resubmit_count": 1
}
```
Only a **flagged** row can be resubmitted.
Anything else is a 409 with the reason: *"resubmit applies only to a flagged row (this row is
'pending')"*.
**A re-run is not guaranteed to do better.**
On the walked example the second pass replaced the original doubt with a blunter one: "no extracted
fields to review".
If the re-run does not help, decide the row yourself.
**Refresh re-reads the selected document.**
After a send-back, Refresh updates both the list and the open row, including reviewer, flags, posting gate and audit trail.
It preserves a half-typed rejection reason while the read is in flight.
## Revise, the v1 to v2 story
**Revise** re-opens the builder with the current values, headed *"revising v1"*, and the button now reads **Save new version**.
The same schema owns both create and revise.
For a currency-bearing document, the current value stays visible in an uppercase ISO 4217 select; an old lowercase, localized or unsupported value is shown as invalid and must be corrected before **Save new version** can send a request.
An unrelated edit cannot clear that error, and a missing schema fails closed instead of resubmitting a currency the server cannot verify.
v2 arrives **Awaiting approval**.
The previous approval does not carry over, and you still cannot approve your own.
Once a designated approver signs it and submits it, it enters the intake queue as its own row.
### The Clerk flags the revision, and asks you to choose
If v1 is still in the queue, v2 does not quietly replace it.
The row lands **flagged**, carries **Duplicate of** with the sibling row's id, and states the rule outright.
**This flag is an instruction, not a warning.**
Approving both rows would post the same invoice twice.
The resolution is two clicks, in this order:
1. **Reject** the version you are not keeping, with a reason such as "superseded by v2".
2. **Approve document** on the one you are.
Only then does the Bookkeeper draft an entry, and only for the version you chose.
The flag names the sibling row by raw id and does not link to it.
To find it, open the **All** tab and match the id, or open the Typewriter document's version history,
where both versions are listed with what happened to each.
## Opening a specific row by link
A review link carries the row's id - `/books/review?item=`, and the older `?intake=` the Typewriter used to emit is still accepted, because those links exist in the wild.
| What the id is | What you get |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| a row in the queue | that row selected, with the tab moved to one that shows it - **the row wins over an explicit tab in the link** |
| a row the loaded list does not hold | confirmed directly against the server, and selected if it exists |
| an id this org cannot see, or that does not exist | **nothing selected**, and a banner naming the id |
That last line is the important one, and it used to be the opposite.
A link with an unknown id once fell back to whatever *Needs review* listed first - a different, real, actionable document with live Approve and Reject controls, and no message anywhere.
Selecting nothing is the correct answer to "open this document" when the document cannot be found.
## Related
* [4 · Gate 1, the intake approval](/greatbook/guides/intake-gate)
* [2 · Sign it](/greatbook/guides/approve-a-document) - versions and supersession in full
* [Reference](/greatbook/guides/reference) - statuses and deep links