Status: Working product map
Purpose: Explain the product flow, link each stage to its requirements, and identify the next decisions.
Each stage starts with a short explanation of its purpose and how it connects to the rest of the product.
It then shows:
A linked brief means requirements are documented. It does not mean the feature is built, tested or approved for live use.
Current-product descriptions are working observations. Jesse and Bahadir will check them against the existing product in Turkey.
Some briefs cover several stages. The repeated links point to the same document.
Company onboarding and data setup can progress in parallel. Real data can only be acquired and used with the required permission.
Permission to use data is not the same as authority to execute a compensation. Concilias must check the required permissions, authority and company limits before each protected action.
The commercial rule is:
Completed only when all closure conditions are met.Completed creates one €5 fee per participating company, charged to its representing Studio.The fee amount is configurable. Signatures, Pratica creation, downloads and individual accounting confirmations do not independently create a fee.
A fee charged to a Studio does not automatically authorize that Studio to pass the charge to its client.
This stage brings a Studio into Concilias. The Concilias team reviews its request, creates the Studio record and invites the first Commercialista to set up access. This establishes the Studio’s account; permission to act for individual companies is collected separately during Company Onboarding.
Features: Access requests, Studio qualification, invitations, onboarding progress, agreements and the internal Concilias Admin Portal.
Current product: Assisted onboarding is partly available.
Requirements: Studio Onboarding and Admin Portal v1.1
Next step: In Turkey, check the existing admission flow, first-Commercialista invitation and account recovery. Confirm who checks identity, professional eligibility and required insurance evidence.
This stage controls how people work inside their Studio’s account. It defines who can manage setup and data, who can review cases, and who is responsible for the next action. Product access is separate from professional eligibility and authority to act for a particular company.
Features: Studio settings, invitations, login, account recovery, Studio Admin and Commercialista capabilities, access permissions, work ownership, notifications and Panorama.
Current product: Partly built.
Requirements: Studio Workspace and Users v1.2
Next step: In Turkey, compare the brief with the existing user accounts, permissions, assignments and notifications.
A person can have Studio Admin capability, Commercialista capability or both. These capabilities do not replace checks of professional eligibility or company authority.
This stage connects each company to its Studio and records the permissions and restrictions that apply to it. The company receives an invitation and can complete the required steps without creating a Concilias account. Agreement status, data permission and authority to participate in compensation remain separate, so Concilias can explain what is allowed and what is still missing.
Features: Company lists, company identity, invitations, a company experience without a Concilias account, agreements, data permission, authority to act, company limits and withdrawal of authority.
Current product: Partly built.
Requirements: Client Onboarding v1.1
Next step: Confirm authority, signing, company restrictions and withdrawal rules with the attorney. Then test the invitation and authorization flow with an approved company sample.
Start here for development:
B00_Current_code_review.md and SHARED_RULES.md.This stage obtains permitted accounting data and prepares it for Concilias. Accountants can see which companies have usable data, how current it is and what needs attention. Production acquisition should run daily without repeated manual work after setup.
Features: Guided source setup, authorized company mapping, manual imports, reusable connections, recurring acquisition, data freshness, coverage, recovery and permitted invoice enrichment.
Current product: Manual acquisition works. Recurring acquisition is incomplete. Existing capabilities must be verified against the code before development.
Reference specifications only — not individual build assignments:
Implementation: Follow the Stage 04 Build Index and its ordered small briefs. Implement and test one brief at a time. For each Codex session, use the selected brief, the shared rules and only the prerequisite handoff notes needed for that build. The full reference documents are not a single implementation assignment.
Build shared capabilities in Turkey with synthetic data. Use Gaia discovery to establish the first supported source route. Buffetti is confirmed by the founder; eBridge and the recurring access method remain to be verified. Prefer cloud operation; a local application is a conditional route.
Next step: Complete B00 — Current code review, then confirm the scope of B01. B00 is review-only. Source discovery may proceed earlier when authorized access is available; a real adapter build requires that evidence.
Validation: Each small brief includes acceptance criteria and short manual checks for Jesse and Bahadir. Real-source reliability, accountant self-service and useful-opportunity yield require separate Studio evidence. Record unavailable required integrations as Blocked, not Pass.
Keep individual brief statuses in the build index. Update this stage’s Current product and Next step as work progresses.
This stage finds possible compensation loops in the available data and presents them in a list accountants can search, filter and prioritize. An opportunity is a candidate for review, not confirmation that the balances are current or that the compensation can proceed. The existing detection engine should remain unchanged unless testing identifies a specific need.
Features: Find compensation loops, calculate possible amounts, create candidates, track versions and source data, and provide a searchable list with ranking and filters.
Current product: The detection engine exists. The opportunity list and case-status handling are partly built.
Requirements:
Next step: In Turkey, identify which invoice fields the product already uses. Test the list and ranking with accountants. Identify development work from demonstrated gaps.
This stage lets the accountant decide whether an opportunity is accurate and suitable to proceed. The accountant checks current balances, confirms or changes the proposed amounts, or rejects the opportunity with a reason. Changes must update the case and preserve its history; an invoice alone does not prove that its full amount is still unpaid.
Features: Check current balances, select Valid / Modify / Reject, record reasons and evidence, recalculate amounts, save work, confirm decisions and keep an audit history.
Current product: Partly built.
Requirements: Opportunity Review through Accounting Closure v1.3.1
Next step: Test search, filters, ranking, wording and review actions with Alberto and other accountants. Include a partially paid invoice: the accountant must be able to confirm the remaining amount without overwriting the original invoice amount.
This stage coordinates a case when its companies are represented by more than one Studio. Each Studio reviews and acts for its own companies, while Concilias shows shared progress, missing actions and permitted contact information. One Studio cannot approve for another, and the whole compensation becomes Completed only when all shared closure conditions are met.
Features: Confirm eligible participants, assign responsibility, share permitted information, collect each Studio’s review, show pending actions and track accounting progress by company.
Current product: Not complete.
Requirements: Opportunity Review through Accounting Closure v1.3.1
Next step: Test a case involving two existing Concilias Studios. Check whether each accountant understands who must act next, what is missing and whom to contact.
Inviting Studios outside the network remains a later feature.
This stage prepares the agreed documents and checks that the right people have authority to sign for every participating company. Execution depends on valid evidence for the approved case version, not simply on collecting one signature per Studio. Once execution is validated, company Pratiche and accounting tasks become available, but the compensation is not yet Completed.
Features: The approved case version, Verbale, annexes, document corrections, company-to-person signing authority, signatures, execution evidence and document integrity.
Current product: Partly built. Live use depends on legal approval.
Requirements: Opportunity Review through Accounting Closure v1.3.1
Next step: Confirm the signing and execution rules with the attorney. Record the answers in the existing brief.
This stage records that each accountant has adjusted the relevant company balances in the books. Concilias tracks confirmations and problems separately for each company, while keeping one shared completion state for the compensation. The case becomes Completed only when every required confirmation and Pratica record is present and no unresolved issue prevents closure.
Features: Accounting instructions, confirmation that entries were posted, balance checks, problem handling, final Pratica records, shared completion and archive.
Current product: Partly built.
Requirements: Completion Event Pratica and Billing v0.2
Next step: Confirm what accountants must record as evidence that they adjusted the books. Test a case where one company is still waiting or reports a problem.
This stage records the fees created by a completed compensation and assigns each company’s fee to its representing Studio. It also supports statements, corrections and the history needed to explain what happened. Fee creation, invoicing and payment collection are separate events; repeating a confirmation or retrying a failed task must not create another charge.
Features: Fees by company, allocation to Studios, statements, corrections, audit history, support, record retention and operational reporting.
Current product: Partly built.
Requirements: Completion Event Pratica and Billing v0.2
Next step: In Turkey, verify the shared completion event, fee allocation and protection against duplicate charges. Resolve fee disclosure, VAT treatment, billing timing and correction policies before live billing.
Payment collection and advanced invoicing may remain manual initially.
All ten stages have linked developer briefs. Decisions, build gaps and tests remain within those briefs.
Keep these three questions separate:
Legal approval is a separate condition for the affected live actions.
Stage 04 implementation: The Build Index assigns the acquisition and enrichment requirements to ordered, bounded briefs. B13 records source discovery and the route-specific evidence; B14 implements one verified source adapter. Complete the source-specific addendum before that adapter build. The reference versions are Data Acquisition v4.1 and Data and Opportunity Enrichment v0.4.
Use one example: three companies, two Studios and one partially paid invoice.
Follow it from company permission and data acquisition through review, execution, accounting closure and fees.
At each step, record:
Use the results to agree the smallest end-to-end build before estimating the wider roadmap.