Skip to main content

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:ProfileIDurn: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

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