> For the complete documentation index, see [llms.txt](https://docs.cottfile.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cottfile.com/clerk-guide/standalone-parishes.md). # Standalone Parishes Some parishes use CottFile for e-filing while keeping their own case management system. If your parish is set up this way, CottFile never writes to any case management system -- your office enters accepted filings into your own system, and CottFile adapts in a few visible ways. Everything else in the clerk guide works the same. ## Case Numbers Come From Your System CottFile never issues a case number at a standalone parish -- your case management system does. So: ### At acceptance, the case number is optional The Accept dialog has a **Case number (optional)** field (placeholder "e.g., 2024-12345"). Its help text explains: "Stamped onto the documents. Leave blank if this case hasn't been entered into your case management system yet -- you can add the number from the queue afterwards, and the stamp will simply omit it." ### Adding or editing the number afterwards An **Add case #** link appears in the queue's Case # cell and in the review panel's Filing Info Case # row (placeholder "e.g. FA-COTT-2026-00161"). Type the number your system assigned and save. * If you accepted with the field blank, the stamp simply omits the case number. Adding the number later does **not** change the stamp already on the documents. * An existing number stays editable (**Edit case number**). {% hint style="info" %} **📹 GIF:** Accepting a filing with the case number field left blank, then clicking "Add case #" in the queue's Case # cell and typing the number assigned by the parish's own system. {% endhint %} ## Editable Case and Filing Types Because reference data is not synced from a case management system, **Case Type** and **Filing Type** are editable on the review screen -- even on existing cases. (Your admin portal is where the lists themselves are maintained.) ## Deposits and Fees * A local **Deposit** docket entry type is created automatically for your parish. It powers the filer's **Add deposit** option and your **Collect deposit** field ("New money added to the ledger") on the review screen. * Deposits and fees are charged to the filer's card at acceptance, exactly as at any other parish. Nothing is posted to any case management system. * There is no **Ledger Balance** column and no **Remaining Ledger Balance** row -- the deposit ledger lives in your own system. ## What the Accept Dialog Leaves Out Compared to other parishes, the Accept dialog at a standalone parish: * Has the **Case number (optional)** field described above. * Has no **Assign Filing To** party selector. * Has no case-management-system **Filing Date** block. The acceptance overlay's last step reads "Recording the filing". ## Automatic Print Handoff So your office always has paper to enter into its own system: * Every document on an accepted filing is added to the accepting clerk's print queue automatically. * Judge-signed filings are handed to the print queue the same way -- the footer button on a signed filing reads **Send to print queue** (instead of **Record signed version**). See [Printing](/clerk-guide/printing.md) for working the print queue. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.cottfile.com/clerk-guide/standalone-parishes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.