> ## Documentation Index > Fetch the complete documentation index at: https://docs.denari.com/llms.txt > Use this file to discover all available pages before exploring further. # Document requests > Ask a client for the documents you're waiting on, and review what they send back. Publishing pushes documents *out* to a client. **Document requests** pull them *in*: a named list of what you're still waiting on, shown to the client as a checklist they fulfill by uploading. Document requests are behind their own feature flag while the feature settles. If the **Document requests** section doesn't appear on your portal pages, ask the Denari or IT admin at your firm to enable it. ## Where they live Open a portal from **Portals** in the product switcher. Below the documents card is a **Document requests** section — *"What you're waiting on — the client sees these under 'Waiting on you'."* Two buttons sit in its header: | Button | Does | | - | - | | **New request** | Creates one request, typed out here | | **Templates** | Opens your firm's saved checklists — see [Request templates](/portals/request-templates) | Before you've asked for anything, the section reads **Nothing requested from this client yet.** The Document requests section on a portal page, with Templates and New request buttons and four requests showing Received, Submitted, Sent back, and Open badges. ## Ask for one document The dialog is titled **Request a document — client entity name**, so you can confirm whose portal you're about to post to. **What are you asking for?** is the whole identity of the request and the only required field — free text, up to 255 characters. Write it the way the client would recognize it: *December 2025 bank statements*, not *BS-DEC25*. **Note (optional)** is shown to the client under the request title. Use it for the qualifier that prevents a wrong upload — *all accounts, including the new one*. **Due date (optional)** renders to the client as *Due Dec 15*. Leave it empty and the request simply has no date. Click **Send request**. A **Request sent** toast confirms, and the item appears immediately in the client's **Waiting on you** list. The Request a document dialog, with a title field, an optional note, and an optional due date. One request per document you want back. Bundling *"bank statements, payroll reports, and the fixed asset schedule"* into a single request gives the client one **Upload** button for three unrelated things, and gives you nothing to mark received independently. ## The four statuses A request moves through four states. **The client never sets a status** — an upload and your review are what move it. | Status | You see | The client sees | Meaning | | - | - | - | - | | Open | **Open** | **Open** | Asked for, nothing sent yet | | Submitted | **Submitted** | **With your firm** | The client uploaded; it's waiting on your review | | Received | **Received** | **Received** | You accepted it. Done. | | Sent back | **Sent back** | **Sent back** | You rejected it with a reason; the client can upload again | The two vocabularies are deliberate. *Submitted* describes your review queue; *With your firm* tells the client the ball is in your court. Same state, same badge color, different words. ## The lifecycle It starts **Open**. The file lands in your intake review queue and the request flips to **Submitted** on its own. Clients can upload against **Open** and **Sent back** requests only. **Mark received** accepts it. **Send back…** rejects it with a reason and returns it to the client, who can upload again. Or bounces between **Sent back** and **Submitted** until it's right. A request's status tracks the **ask**, not the file. Marking a request received does not file the uploaded document — that still happens in your [intake queue](/documents/intake), where the upload is waiting. ## Review what comes back Each row in the staff list shows the title, `Due · Requested `, the note, and the status badge. The `⋯` menu on the right holds every action: | Action | Available when | Result | | - | - | - | | **Mark received** | Any status except Received | Status → **Received**, toast *Marked received* | | **Send back…** | Submitted or Received | Opens the reason dialog | | **Cancel request** | Always | The request is withdrawn and disappears, toast *Request cancelled* | ### Sending one back **Send back…** opens a dialog titled **Send back — request title**, warning you that *the client sees your reason and can upload again*. The reason is **required** — you cannot send a request back silently. Write what would let the client get it right on the second try: > This was the 2023 bill — we need the 2024 one The Send back dialog for a request, with a required reason box the client will see. Click **Send back**. The client's row turns red, your reason appears under the title, and their **Upload** button comes back. You can send back a request you'd already marked **Received** — useful when a document turns out to be wrong after you filed it. The client sees the same reason and the same second chance. ### Cancelling **Cancel request** withdraws the ask entirely. It disappears from both your list and the client's, at any status. Use it when you asked for something you no longer need; use **Mark received** when you got it. ## What the client does The client sees a **Waiting on you** section above their documents — *"Documents your firm has asked you to send."* Every request is a row with: * The title, and your note in a highlighted pill. * A date line: `Due Dec 15` while open, then `Sent`, `Sent back`, or `Received` with the date of that transition. * The status badge, in client language. * An **Upload** button, on **Open** and **Sent back** rows only. The client's Waiting on you checklist, showing requests badged Open, Received, With your firm, and Sent back, with Upload buttons on the actionable rows. Uploading accepts several files at once and shows *Sending 1 of 3…* as it works. Every file for a request joins one review batch on your side, titled by the request, so you can tell a request's uploads apart from the client's other sends. Files are capped at **50 MB** each, and the allowed types are PDF, PNG, JPEG, WebP, HEIC, Word, Excel, CSV, and plain text. Anything else is refused with an inline message on the file's row. Client uploads never land in your library directly. They arrive in the **intake** review queue, pre-routed to the client entity, and become library documents only once your firm files them. See [Where documents land](/documents/where-documents-land). ## Seeing what's outstanding Outstanding requests live **on each portal**, not in a firm-wide list. To see what a client still owes you, open their portal and read the **Document requests** section — the badges tell you where each one stands at a glance: | Looking for | Scan for | | - | - | | Not sent yet | **Open** badges | | Waiting on your review | **Submitted** badges | | Bounced back, waiting on the client again | **Sent back** badges | | Done | **Received** badges | **There is no roll-up of outstanding requests across clients**, in the Admin section or anywhere else. **Admin → Clients** lists the people your firm has invited to portals — their email, which client entities they can see, and whether their invitation was accepted — but it does not report on requests. To review what's outstanding across a book of clients today, you open each portal in turn. If a firm-wide view would help your team, raise it with your Denari contact. ## Good to know * **Requests are per client entity.** A client group with three entities has three separate request lists. * **Nothing is emailed.** Creating a request does not notify the client — it appears the next time they open the portal. If it's urgent, tell them. * **A client with no requests sees no checklist at all**, not an empty one. The section simply isn't rendered. * **Cancelling is not the same as receiving.** Both clear the row; only **Mark received** records that you got the document. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.