> ## 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.

# 4 · Gate 1, the intake approval

> Read the flags, then decide. Approving says the document is real and correctly extracted, and moves no money.

# 4 · Gate 1, the intake approval

**What you are doing.** Answering one question: *is this document real and correctly extracted?*

You are not deciding how it should be booked.
That is gate 2, and it belongs to a different person.

## Read the flags, then decide

For anything the Clerk was unsure about you get a **flags** block naming each concern: a possible duplicate of an existing queue item, a missing related document in the chain, a classification it could not settle.

Resolve each one in your head, then choose.

| Move                 | Use it when                                                                     | Reversible?                                                  |
| -------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| **Approve document** | it is real and correctly extracted                                              | the approval is; the posting after it is a separate decision |
| **Send back**        | the document is genuine but the agent read it badly                             | yes, it comes back                                           |
| **Reject**           | it should not be in the books at all: a test, a duplicate, a superseded version | no. Compose or upload again                                  |

<Note>
  **Duplicates.** A `source_ref` flag reading "possible duplicate of queue item …; verify this is not a
  re-upload" is the Clerk asking you to look, not telling you it is a duplicate.
  The detail pane also shows **Duplicate of** with the sibling row's id.
</Note>

## Confirm, and understand what you are confirming

Approving asks you to confirm, and the confirmation says precisely what happens next: the Bookkeeper drafts a journal entry and stops.

```http theme={null}
POST /intake/{intake_id}/approve
X-WorthState-Org-Id: <org>
```

```json theme={null}
200 OK

{
  "id": "<intake row id>",
  "status": "active",
  "approved_by": "<the server-derived actor>",
  "launch": {
    "status": "launched",
    "error": null,
    "retryable": false
  }
}
```

## What just happened underneath

Two things, and they are deliberately separable.

**The approval is durable the moment that request returns 200.**
It is written, attributed and stamped in the audit trail.

**The Bookkeeper launch that follows it can still fail.**
The handoff is an **outbox, not a call**: the approval does not wait on the agent, and the agent's start is a job that gets finished afterwards.

That is why the response carries a `launch` block.
A reviewer is told when the launch failed and whether it is retryable, rather than being shown an unconditional success for an operation that may have done nothing.
Two endpoints finish the job: a retry for one row, and a sweep for all of them.

<Note>
  Within seconds the row leaves **Needs review** and appears under **Awaiting posting**.
  The audit trail now shows two events: your `approve`, then `bookkeeper_launched`.
</Note>

## What you cannot do here, and why

**Approving here does not move money.**
It advances the row and starts the Bookkeeper.
The ledger is untouched, and it stays untouched until a *different* person approves the posting.

**You cannot approve a document you submitted.**
The intake gate enforces its half of the separation-of-duties rule at the gate you are standing at, rather than letting the row become active and turn out to be permanently unpostable two steps later.

The refusal is a 409 with a readable reason:

> separation of duties: '…' submitted this document and cannot also approve it

**A document with no recorded submitter cannot be approved at all.**

> this document has no recorded submitter, so approving it would leave nobody accountable for having filed it. It has to be re-submitted by the person who owns it

That refusal exists because "nobody is recorded as having submitted this" and "you cannot approve your own document" are two very different things to tell someone standing at a money gate, and the system checks for the first before it checks for the second.

<Warning>
  **Rejecting is terminal, and your reason is the only explanation anyone will ever see** for why this
  document never reached the books.
  The reason field is optional to the form and essential in practice.
</Warning>

## Next

<Card title="5 and 6 · The Bookkeeper drafts, then gate 2" icon="stamp" href="/greatbook/guides/posting-gate" horizontal>
  The proposed debits and credits, and the refusal that proves the rule is real.
</Card>

## Related

* [Working the review inbox](/greatbook/guides/review-inbox) - reject, send back and revise in full
* [Who does what](/greatbook/roles) - the three-distinct-people rule