> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # How Lerian CCS works > How Lerian CCS builds the daily ACCS001 batch, submits it through Lerian STA, records detail requests and transfers, and reconciles the accepted position. Lerian CCS runs one regulatory cycle per **movement date** and per **configuration**. Every file that leaves or reaches Lerian CCS travels through [Lerian STA](/en/rails/native/sta/what-is-lerian-sta), and every state change lands in the audit chain. ## Where the customer data comes from *** Lerian CCS keeps no copy of your customer base. **Lerian Reporter** renders the daily ACCS001 file from your customer data against a registered template. Lerian CCS reads the rendered bytes and creates one batch line item per operation in the file. The Reporter is a mandatory upstream. Lerian CCS refuses to start without the Reporter address, and an unreachable Reporter takes Lerian CCS out of the ready state. An empty ACCS001 template identifier refuses the approval with `MYS-0008`. ## Reporting (ACCS001) *** A batch belongs to one movement date. One rule answers which movement date the institution may transmit now, and whether a supplied date is acceptable. A date outside the rule fails with `CCS-0012`. The batch then walks a state machine: | State | What it means | | ----------------------------------------------------------------- | ------------------------------------------------------------ | | `GENERATING` → `GENERATED` | Lerian CCS builds the batch and validates it. | | `PENDING_REVIEW` | The batch waits for an operator decision. | | `AWAITING_RENDER` | An operator approved the batch, and the render is in flight. | | `SUBMITTED` | The rendered bytes landed and went to Lerian STA. | | `FORMAT_ACCEPTED` | The transmission completed. | | `ACCEPTED` | BACEN accepted the remittance. | | `PARTIALLY_REJECTED` | BACEN took the file and refused some records. | | `FORMAT_REJECTED` | BACEN refused the file. | | `REJECTED`, `GENERATION_FAILED`, `RENDER_FAILED`, `SUBMIT_FAILED` | Terminal failures. | Approve and reject are the only operator decisions on a batch under review. Approve dispatches the render and parks the batch, so no synchronous path reaches the hand-off. A render that gives up ends in `RENDER_FAILED`, and recovery is a fresh batch. BACEN answers on the inbound file channel. An ACCS002 carries the file-level verdict. An ACCS003 carries one verdict per record, and Lerian CCS matches each verdict to its line item by the regulatory tuple. A verdict that matches no line item fails closed rather than dropping in silence. An accepted record promotes its relationship into the accepted position. A refused record leaves an error row your operators can read. After a refusal, an operator can create a resend batch from the terminal source. A background monitor asks, per configuration and movement date, whether BACEN acknowledged a remittance dated on that date. It answers `PRESENT`, `MISSING` or `UNDETERMINED`. The obligation holds even with no movement, so `MISSING` is a regulatory omission. `UNDETERMINED` says the control could not answer. ## Detail requests (CCS0001 and CCS0003) *** BACEN sends a detail request as a file. Lerian STA downloads it and hands the reference to Lerian CCS over the message broker. `CCS0001` asks by person and `CCS0003` asks by account. Lerian CCS is idempotent on the correlation identifier. It parses the file, derives the document hash and the ciphertext, and computes the regulatory deadline from the banking calendar. It writes the request and its audit row in one transaction. Your operators list the requests, ordered by deadline, with every document masked. An operator can cancel a request that is still `RECEIVED` or `PROCESSING`. A cancellation after the window closes returns `CCS-0066`. BACEN also sends penalty reports as ACCS009 on the same channel. That document is a columnar text report with no XML layout. Lerian CCS parses it and stores the occurrence. ## Transfers (ACCS010 to ACCS012) *** A transfer moves relationship legs to another institution, named by its CNPJ root. An operator creates the transfer as a draft together with the legs it covers. Your operators list transfers newest first, up to 200 per page, and read any transfer with its legs. ## Compliance and injunctions (ACCS004) *** BACEN publishes the position it holds for the institution as an ACCS004. Lerian CCS parses that report and runs a reconciliation against the accepted position it keeps. Only one run per configuration may be in progress. A run ends as `COMPLETED` with its match and divergence counts, or as `FAILED` with a diagnostic. Your operators list the divergences of a run, with each document masked to its last four characters. The comparison keys on a keyed hash of the document. Lerian CCS never stores a cleartext document. It encrypts a document only when a divergence row must retain it. An injunction records a judicial `BLOCK` or `UNBLOCK` against one document for one configuration, under LC 105/2001. A block holds that identity out of the remittance. An operator can revoke an active injunction, and the revocation is soft. ## Audit trail and events *** Every state change writes an entry to an append-only audit log, inside the same transaction as the change itself. Each entry carries the SHA-256 of the previous entry combined with the canonical form of the record, so the entries form one chain per institution. An operator can ask the service to verify a chain end to end. Lerian CCS also publishes a business event when the ACCS001 batch goes to Lerian STA. It writes the event through a transactional outbox, so the event and the state change it reports commit together. Event publication over the streaming topic stays off until an operator turns it on.