> For the complete documentation index, see [llms.txt](https://docs.allshore.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.allshore.ai/clients-and-pipeline/client-sign-offs.md).

# Client sign-offs

**Client sign-offs** is your side of timesheet approval: which submitted weeks are waiting on a client, what each client decided, and the controls for when a decision doesn't come.

## The lifecycle

A consultant's week goes **draft → submitted**, then waits on the client. From there it becomes **client approved** or **rejected**.

Who decides: the **client admin** in their portal. Client viewers can see approvals but not decide. You can decide on a client's behalf — see Overrides below.

Approval is the gate on billing: invoicing prices approved time. A week nobody has signed off doesn't reach an invoice.

## A week that spans two clients

This is the case worth reading twice, because it's the one that surprises people.

A consultant can log billable time for **two different clients in the same week**. When they submit, **each client decides only its own portion** — Client A never sees or decides Client B's days.

The sheet's *status* is the whole week's:

* **Every client carrying billable time must approve** before the week becomes client approved.
* **Any one client's rejection rejects the whole week.**

But billing is decided **per client**, not by the sheet's status — and that distinction matters more than the status does:

> **A rejection does not revoke another client's approval.** If Client A approved and Client B rejected, the week reads *rejected*, and **Client A's portion is still billable** on the strength of A's own approval row. It stays billable until the week is reopened or resubmitted, which clears the recorded decisions.

So "the week was rejected" does not mean "nothing bills". If a rejection means you don't want *any* of that week invoiced yet, reopen it — that's what actually clears the approvals.

The flip side: reopening to fix Client B's days **discards Client A's approval too**, and A has to sign off again after resubmission. Worth warning the other approver that a second request is coming.

Internal and non-billable time belongs to no client, so it never needs a decision and never blocks billing.

One rough edge to know: a week made up **entirely** of internal time still shows in the sign-off queue after it's submitted, with nobody to wait on — there's no client to decide it, so it never resolves on its own and simply sits there. Ignore those rows; they aren't holding anything up.

## Overrides and reopening

* **Override** — record a decision on a client's behalf, attributed to you and audited as an override. It applies only to a **submitted** sheet: once a week is terminal you reopen it first. You can only override for a client that actually has time on that sheet.
* **Reopen** — send a week back to the consultant for correction, **clearing every client decision recorded on it**. You can reopen a week that's still submitted and only partly decided — that's the usual case when one client has answered and another hasn't, and you need the consultant to change something. Reopening is **refused once any of the week's time has been invoiced**: billed time is not silently unwound. If something billed is wrong, fix it on the invoice rather than under it.

## Decision history

While a week is in the sign-off queue, it carries an activity timeline: who decided, for which client, when, and any rejection comment.

Note the limit: this screen shows **submitted** weeks. Once a week is approved or rejected it leaves the queue, and its timeline is no longer reachable here — so if you're likely to need the detail of a decision later, capture it while the week is still in the queue.

## About automatic approval

The platform has a mechanism to approve a week on a client's behalf when no decision arrives within a set number of days. **It requires a per-client policy, and there is currently no screen or setting that creates one** — so in practice nothing is auto-approved today: every approval on your account is a real decision by a client admin or a partner override.

If a policy ever is in place for a client, an approval it produces is not disguised: the decision history shows *"Auto-approved for \<client> — no decision in time"* with the actor recorded as **automatic**, so you can always tell a human decision from a lapsed one.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.allshore.ai/clients-and-pipeline/client-sign-offs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
