# Change Request Template

# Change Request Process: Bilko

> **Project:** Bilko — Balkan Accounting SaaS
> **Version:** 0.1
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Draft
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | 2026-02-23 | John (AI Director) | Initial draft — Bilko change control process |

---

> **NOTE:** This file documents the **Bilko Change Request Process** and provides the template for individual Change Requests. Copy the CR Template section below for each new CR, replacing all fields. Save individual CRs as `CR-XXX-title.md` in the same directory.

---

## Bilko Change Control Overview

Bilko is an accounting SaaS with regulatory compliance requirements (SEF, PDV, GDPR). Changes to approved requirements carry additional risk because:

1. **Accounting law compliance** — a scope change to invoice or VAT logic may break Serbian legal requirements
2. **Double-entry integrity** — changes to the transaction model can corrupt financial records
3. **SEF API compatibility** — invoice format changes may cause SEF rejections for existing users

**Therefore:** ALL scope, requirement, budget, or timeline changes must go through this process. No exceptions for "small" changes.

---

## Change Request Log

| CR ID | Title | Submitted By | Date | Type | Impact | Status | Decision Date |
|-------|-------|-------------|------|------|--------|--------|--------------|
| CR-001 | — | — | — | — | — | — | — |

> Add each CR to this log when submitted. Keep this file as the single-page overview; individual CR details in separate files.

---

## Approval Matrix

| Budget / Timeline Impact | Required Approvals | Target Decision Time |
|-------------------------|--------------------|---------------------|
| None | John | 1 business day |
| < 5% budget OR < 3 days timeline | John | 1 business day |
| 5–15% budget OR 3–14 days | John → Alem | 3 business days |
| > 15% budget OR > 14 days | John + Alem | 5 business days |
| Regulatory change (SEF, PDV, GDPR) | John + Alem + Asmir | 5 business days |

---

---

# CR Template — Copy Below for Each New Change Request

---

# Change Request: [CR Title — short imperative description e.g. "Add Croatia PDV 25% rate support"]

> **Project:** Bilko — Balkan Accounting SaaS
> **CR ID:** CR-[NNN] _(assigned by John — use next sequential number from the CR log)_
> **Version:** 0.1
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Draft
> **Reviewers:** Alem Bašić (CEO)

## 1. Change Request Metadata

| Field | Value |
|-------|-------|
| **CR ID** | CR-[NNN] |
| **Date Submitted** | 2026-02-23 |
| **Submitted By** | John (AI Director) |
| **Project** | Bilko |
| **Priority** | Critical / High / Medium / Low |
| **CR Type** | Scope Change / Budget Change / Timeline Change / Requirements Change / Regulatory Change / Technical Change |
| **Current Phase** | Planning / Design / Development / Testing / Deployment |
| **Decision Deadline** | [DATE — by when Alem must decide to avoid delaying the next sprint or launch milestone] |

---

## 2. Change Description

### 2.1 Summary of Change

[One paragraph: what is changing, why it is changing, and what the expected outcome is. Be specific — name the feature, module, or regulation driving the change. Example: "The Serbian Tax Administration updated the SEF e-invoice schema (version 2.1) effective 2026-04-01. The current Bilko SEF integration targets schema version 2.0. Without this change, all invoice submissions will be rejected by SEF from April 1, resulting in legal non-compliance for all Serbian Bilko users."]

### 2.2 Current State (Before)

[Describe the current approved state in concrete terms. What does the system do today? What requirement, architecture, or document describes this current behavior? Example: "The invoice submission module (apps/api/src/routes/invoices/) generates SEF XML using schema v2.0. The UBL namespace is 'urn:oasis:names:specification:ubl:schema:xsd:Invoice-2' as specified in FR-042."]

**Currently approved in:** `[Document name and version e.g. functional-requirements.md v1.2]`, Section [X.X]

### 2.3 Proposed State (After)

[Describe what the system should do after this change, with enough detail for implementation. Include field names, schema names, API changes, or UI changes as appropriate. Example: "Update the SEF XML generator to produce schema v2.1. New required field: <cbc:ProfileID>urn:fdc:sef.gov.rs:2021:billing</cbc:ProfileID>. Update the validator to check v2.1 compliance before submission. No UI changes required — the change is in the API layer only."]

### 2.4 Out of Scope for This Change

This CR does NOT include:
- [First explicitly excluded item — something adjacent that might be assumed but is not in scope. Example: "BiH or Croatia e-invoice format changes — these are tracked separately."]
- [Second explicitly excluded item. Example: "UI changes to the invoice creation wizard — no user-visible changes in this CR."]

---

## 3. Reason & Justification

### 3.1 Reason for Change

| Reason Category | Applies? | Details |
|----------------|---------|---------|
| New business requirement discovered | Yes / No | [Describe if applicable, otherwise "N/A"] |
| Regulatory / compliance mandate (SEF, PDV, GDPR) | Yes / No | [Which regulation, effective date, enforcement body — e.g. "SEF schema v2.1 mandatory from 2026-04-01 per RS Tax Administration notice"] |
| Technical blocker / infeasibility | Yes / No | [What technical limitation was discovered and why it blocks progress] |
| Market opportunity / competitive pressure | Yes / No | [Market context if applicable] |
| Error/omission in original requirements | Yes / No | [What was missed in the original spec and when discovered] |
| Beta user feedback | Yes / No | [Which beta user(s) raised the issue, what they reported] |

**Primary Justification:**
[One clear statement of why this change must happen. Focus on business impact: revenue risk, legal obligation, user blocking issue, or architectural necessity. Example: "Serbian law requires SEF-compliant invoices. Schema v2.0 becomes invalid on 2026-04-01. All Serbian users will face fines and invoice rejections if Bilko does not update. This is a non-negotiable legal compliance change."]

### 3.2 Consequence of Not Changing

If this change is **not** approved:
[Concrete consequences — be specific about legal, financial, or user impact. Example: "All Serbian Bilko users will be unable to submit e-invoices to SEF from April 1. This exposes users to fines under Serbian tax law and exposes ALAI to liability. Bilko becomes non-compliant and unsellable in the Serbian market."]

---

## 4. Impact Analysis

### 4.1 Scope Impact

| Deliverable Affected | Current Scope | Proposed Scope | Impact Type |
|---------------------|--------------|----------------|-------------|
| [Name of module, feature, or document affected e.g. "SEF XML generator"] | [What it does today] | [What it will do after the change] | Added / Removed / Modified |

**Scope Change Size:** Small (< 1 day) / Medium (1–3 days) / Large (3–10 days) / Major (> 10 days)

### 4.2 Timeline Impact

| Milestone | Current Date | New Date (if approved) | Delay |
|-----------|------------|----------------------|-------|
| [Milestone name affected by this CR e.g. "Backend: SEF integration complete"] | [Current planned date] | [New date if CR approved] | [N] days |
| Serbia production launch | 2026-05-01 | [New date if delayed, or "No change"] | [N] days |

**Timeline Impact:** None / Minor (≤ 3 days) / Moderate (4–14 days) / Major (> 14 days)
**Critical Path Impact:** Yes / No

### 4.3 Budget Impact

| Cost Category | Current Budget (EUR) | Additional Cost (EUR) | Notes |
|--------------|---------------------|----------------------|-------|
| Development | [Current allocated amount] | [Extra hours × rate, or 0 if within capacity] | [Explain if using builder agents or external dev] |
| Testing | [Current allocated amount] | [Extra testing effort cost, or 0] | |
| **Total Additional Cost** | | **[Sum of additional costs]** | |

**Budget Impact:** None / Minor (< 5%) / Moderate (5–15%) / Major (> 15%)

### 4.4 Accounting/Regulatory Impact

<!-- This section is Bilko-specific — critical for accounting software -->

| Area | Impact | Details |
|------|--------|---------|
| SEF compatibility | Affected / Not Affected | [If affected: which SEF fields or schema version changes; if not: "No changes to invoice submission flow"] |
| PDV calculation logic | Affected / Not Affected | [If affected: which VAT rates or calculation rules change; if not: "No changes to PDV computation"] |
| Double-entry integrity | Affected / Not Affected | [If affected: which debit/credit posting rules change; must be verified with accounting test dataset] |
| Audit trail (LoggedAction) | Affected / Not Affected | [If affected: which new actions need to be logged; LoggedAction is append-only] |
| GDPR compliance | Affected / Not Affected | [If affected: which personal data fields are added, removed, or accessed differently] |
| Balkan GAAP | Affected / Not Affected | [If affected: which accounting standard rules (RS/BA/HR) this touches] |

**Regulatory review required:** Yes / No
**If yes, reviewer:** Asmir Merdžanović (SnowIT) + Alem

### 4.5 Risk Impact

| Risk | Probability | Impact | Notes |
|------|------------|--------|-------|
| [New risk introduced by this change e.g. "SEF migration introduces regression risk on existing invoices"] | H/M/L | H/M/L | Add to risk-register.md |
| [Existing risk affected by this change e.g. "SEF rejection risk — currently Medium, may change"] | H/M/L | H/M/L | Update risk-register.md entry |

### 4.6 Quality Impact

- Test cases affected: [List TC IDs needing update e.g. "TC-042 (SEF XML validation), TC-043 (invoice submission end-to-end)"]
- Regression risk: High / Medium / Low — [Explain why e.g. "Medium — changes XML generation layer only; no changes to PDV logic or double-entry posting"]
- NFRs affected: [List any non-functional requirements impacted e.g. "NFR-07 (SEF submission < 2s) — must re-test performance with new schema"]
- Double-entry balance check: Affected / Not Affected

### 4.7 Affected Deliverables / Documents

| Document | Section | Type of Change | Owner |
|----------|---------|---------------|-------|
| `functional-requirements.md` | FR-[NNN — the FR this CR modifies] | Modify | John |
| `user-stories.md` | US-[NNN — affected user stories] | Add/Modify | John |
| `acceptance-criteria.md` | AC-[NNN — ACs that need updating] | Update | John |
| `requirements-traceability-matrix.md` | Row for FR-[NNN] | Update | John |
| `risk-register.md` | R-[NNN — risk entries to add/update] | Add/Update | John |
| `PIPELINE.md` | Status | Update | John |
| `packages/database/prisma/schema.prisma` | Model [ModelName — if schema change required] | Modify | Tech Lead |
| Test cases | TC-[NNN — test cases to update or add] | Update / Add | QA |

---

## 5. Alternative Approaches Considered

| Alternative | Description | Why Rejected |
|-------------|-------------|--------------|
| Option A (Proposed) | [Describe this CR's proposed solution] | _Recommended_ |
| Option B | [Describe an alternative approach considered e.g. "Delay SEF update to post-launch, notify users manually"] | [Why this alternative is inferior e.g. "Does not meet legal deadline; exposes users to fines"] |
| Option C — Do Nothing | Reject the change; proceed as originally planned | [State the consequence e.g. "Serbian market becomes non-compliant; all SEF submissions fail from April 1"] |

**Recommendation:** Option A / B / C
**Rationale:** [One sentence on why the recommended option is the best choice given cost, risk, timeline, and compliance tradeoffs]

---

## 6. Implementation Plan

### 6.1 Implementation Steps

| # | Task | Owner | Effort | Target Date |
|---|------|-------|--------|-------------|
| 1 | [Primary implementation task — describe the code change e.g. "Update SEF XML generator to produce schema v2.1"] | John / builder agent | [Estimated effort e.g. "4h"] | [Target date] |
| 2 | Update affected FR/US/AC documents | John | 1h | [Target date] |
| 3 | Update test cases | validator agent | [Estimated effort] | [Target date] |
| 4 | If schema change: create Prisma migration | builder agent | [Estimated effort, or "N/A if no schema change"] | [Target date] |
| 5 | Regression testing | validator agent | [Estimated effort] | [Target date] |

### 6.2 Dependencies

| Dependency | Type | Blocking? |
|-----------|------|----------|
| [Name any dependency this CR has e.g. "SEF schema v2.1 spec published by RS Tax Administration" or "Prisma migration must run before deployment"] | Internal / External / Regulatory | Yes / No |

### 6.3 Test Plan for This Change

- Unit tests: [List which unit test files need new or updated tests e.g. "sef-xml-generator.test.ts — add tests for v2.1 fields"]
- Integration tests: [List which integration tests to re-run e.g. "Invoice submission end-to-end against SEF sandbox"]
- Accounting validation: [If financial logic changed: describe the test dataset and balance verification. If not: "Not required — no changes to PDV or double-entry logic"]
- SEF sandbox test: [If SEF affected: "Yes — must pass full submission cycle in SEF test environment before production deploy". If not: "Not required"]
- Regression scope: [Which existing features to regression-test e.g. "All invoice creation paths, PDF generation, existing SEF submissions"]

---

## 7. Rollback Plan

**Rollback Trigger:** [Define the condition that would trigger a rollback e.g. "SEF rejection rate exceeds 5% within first 24h of production deploy" or "Balance sheet imbalance detected in accounting integrity check"]

**Rollback Steps:**
1. Revert to previous deployment (git revert or container rollback)
2. Run accounting integrity check: `SELECT SUM(debit) - SUM(credit) FROM transactions` — must be 0
3. Notify affected users if data was migrated
4. Restore DB to pre-migration snapshot if schema was changed

**Rollback Owner:** John
**Rollback Time Required:** < 1 hour for code rollback; up to 4 hours if DB migration involved
**Data Recovery Needed:** Yes (if schema migration) / No (if code-only)

---

## 8. Approval Workflow

### 8.1 This Change Requires

- [ ] **John Review** — Impact analysis complete and accurate
- [ ] **Regulatory Review (Asmir)** — Only if SEF, PDV, or accounting law affected
- [ ] **Alem (CEO)** — Budget > 15% OR timeline > 14 days OR regulatory decision

### 8.2 Decision Record

| Level | Reviewer | Decision | Date | Comments |
|-------|----------|----------|------|----------|
| AI Director (John) | John | Approved / Rejected / Deferred | [Date of decision] | [Any conditions, concerns, or notes] |
| Regulatory (Asmir) | Asmir Merdžanović | Approved / Rejected | [Date of decision] | _(if required — only for SEF/PDV/GDPR changes)_ |
| CEO (Alem) | Alem Bašić | Approved / Rejected | [Date of decision] | _(if required — budget > 15% or timeline > 14 days)_ |

**Final Decision:** APPROVED / REJECTED / DEFERRED
**Decision Date:** [Date the final decision was recorded]
**Effective From Sprint:** Sprint [Sprint number when implementation begins]

---

## 9. Change Log

| Date | Changed By | What Changed |
|------|-----------|-------------|
| 2026-02-23 | John | Template initialized |