· AugmentERP
PRAL SoW · Gap analysis · Code-verified · 31 Jul 2026

PRAL ERP scope of work · implementation status · 2026-07-31

Gap
Analysis

PRAL's ERP Scope of Work assessed against the AugmentERP codebase, requirement by requirement: implementation status, per-module scoring, and the work required to close the gaps.

1 · The requirements 2 · Scoring 3 · Implemented vs missing 4 · Effort & risks
Four independent code audits · branch dev @ ef97c004 · status is evidence-based, not roadmap-based
navigate · F fullscreen

Summary of findings

Overall weighted readiness is approximately 46%.

The accounting spine (GL, AP, AR, banking), Pakistan-localised payroll, the approval engine, RBAC and the audit trail are mature and verifiable in code. Budgeting, the procurement front-funnel, inventory and fixed assets are not present, and account for most of the gap.

≈46%
weighted readiness, scored per requirement from code evidence
11
SoW modules assessed · ~120 discrete requirements checked
4
modules with no usable implementation
25
licensed users requested · small deployment, full ERP breadth
Assessment basis ◇ Each requirement was checked against the actual backend and frontend code, with file-level citations recorded in the underlying audit. Design documents without code are scored as planned-only, not as capability. PRAL's evaluators develop software themselves; any response should claim only what is demonstrable.

The requirements

Eight functional modules, plus delivery and contract obligations.

A cloud ERP for 25 users, replacing an existing system. “Minimal customization, only where necessary” indicates a configured-product expectation; PPRA compliance and withholding tax place the evaluation in a Pakistani public-sector frame.

+
01 · Finance
Multi-level CoA, cost/profit centers, dimensions, journals, full budget lifecycle, fiscal close; AP with 3-way matching & withholding tax; AR; cash & bank; statements.

The largest requirement set in the SoW, and the one with the most public-sector weight:

  • General ledger — multi-level chart of accounts, cost centers, profit centers, financial dimensions, journal processing, fiscal-year closing, audit trails.
  • Budget management — annual budgeting, revisions, enforcement controls and utilization monitoring.
  • Accounts payable — vendor management, invoice processing, three-way matching, advances, withholding tax, aging.
  • AR, cash & bank — billing, receipts, aging, bank reconciliation, payment module.
  • Reporting — trial balance, balance sheet, P&L, cash flow, regulatory and ad-hoc reporting.
+
02 · Procurement
Plan → requisition → RFQ → comparative statements & bid evaluation → PO → contract → GRN, vendor performance, dashboards — under PPRA compliance.

The full public-procurement funnel, not only purchasing:

  • Annual procurement planning; purchase requisitions with approval workflows.
  • RFQ generation, comparative statements, bid evaluations.
  • Purchase orders, contract management, goods receipt notes.
  • Vendor performance evaluation and procurement dashboards.
  • PPRA compliance — PRAL is a federal state-owned entity, so the federal Public Procurement Rules 2004 apply: tender thresholds, advertisement rules, evaluation-report formats.
Assessment note ◇ This module carries the largest gap between the SoW and the current codebase — see the scorecard.
+
03 · Inventory & assets
Item master, multi-warehouse stock, barcode, valuation, physical counts; asset register → capitalization → depreciation → transfer → disposal.
  • Inventory — item master & categorization, warehouse and multi-location stock, receipts / issuance / internal transfers, adjustments, physical verification, barcode support, reorder levels, valuation methods, consumption analysis.
  • Fixed assets — registration, categorization, tagging, capitalization, transfers, maintenance records, verification, depreciation management, disposal & retirement, reporting.
+
04 · Payroll
Salary structures, allowances/deductions, increments / bonus / Eid, tax, arrears, loans & advances, final settlements, bank transfer files, emailed payslips, tax certificates.
  • Payroll processing over employee master data with salary structures.
  • Configurable allowances and deductions; increments, bonuses and Eid allowances.
  • Tax calculations, arrears, loans & advances, final settlements.
  • Payroll approvals and reports; bank transfer files for salary disbursement.
  • Payslips delivered by email; annual tax certificates.
+
05 · DMS · BI · Workflow
Central repository with versioning & RBAC; CEO / CFO / procurement dashboards, drill-down, ad-hoc reports without vendor intervention; multi-level approvals with delegation & escalation.
  • Document management — centralized repository, attachments, version control, role-based access, search & retrieval, audit trails.
  • Dashboards & BI — CEO / CFO / Procurement executive dashboards, KPI monitoring, drill-down from summary to transaction, and self-service ad-hoc reporting — explicitly “without vendor intervention”.
  • Workflow — configurable approval hierarchies, multi-level approvals, delegation, notifications, escalations, audit tracking.
+
06 · Delivery & contract
Cloud with 99.5% SLA + penalties, full data ownership, migration incl. 5 years of financial history, banking/email/API integrations, full SDLC deliverables, 5-year support.
  • Cloud hosting (public, private or hybrid), vendor/OEM-managed, 99.5% uptime SLA with penalty clauses, defined RPO/RTO.
  • Data ownership — unrestricted export in standard formats; free handover at exit.
  • Data migration — CoA, vendor & employee masters, fixed assets, opening balances, open AP/AR, five years of historical financial records.
  • Integration — banking systems, email, and future government applications via APIs.
  • 25 full-user licences; BRD/FRS/SRS, fit-gap, testing (incl. performance & security), training; minimum five years post-go-live support.
Cost drivers ◇ The five-year support, SLA penalties, historical migration and PPRA requirements drive more cost and risk than any single feature.

Scoring

Readiness by SoW module.

Each requirement scored from code evidence — Implemented 1.0 · Partial 0.25–0.75 · Planned-only 0.15 · Absent 0 — averaged per module, then weighted by the module's weight in the SoW and in typical public-sector evaluation.

ModuleScore%Wt
Workflow & approvalsno delegation · no true escalation75%6%
Payrollno bank files · no arrears · settlements partial70%12%
Document management3 silos · versioning for policies only70%5%
Security & controlsno MFA / SSO · at-rest encryption partial70%6%
Finance & accountingbudgeting absent · vendor WHT absent66%25%
Data migrationno HR import · no 5-year history tooling45%4%
IntegrationSES-only email · CSV-only banking45%4%
Dashboards & BIno CEO/CFO views · no ad-hoc builder33%8%
ProcurementPO→GRN→3-way real · funnel & PPRA absent20%15%
Fixed assetszero code · 40-requirement BRD exists0%8%
Inventoryno code and no design docs0%7%
Weighted overall ≈46%. Non-functional posture (cloud · SLA · ops) assessed separately at ≈40% — the GCP sandbox pipeline exists; production ops tooling, IaC and SLA evidence do not.

Implemented and verifiable

What exists in code today.

The strongest areas are the ones a public-sector evaluation weighs heavily: statutory compliance, audit trail, segregation of duties. Each item below is implemented across domain, application, API and UI layers.

Pakistan statutory compliance

Seeded and enforced in the live payroll engine

  • FBR FY2025-26 salary slabs seeded · §149 smoothed withholding bases
  • EOBI / PF / OPD schemes with a statutory filings lifecycle
  • PDF tax certificates · emailed payslips with delivery tracking
  • NTN / STRN on the vendor master · paisa-exact pay-run engine

Platform controls

Enforced at the platform level, not per-screen

  • SHA-256 hash-chained, tamper-evident audit log written for every domain event
  • Segregation of duties enforced in code — submitter ≠ approver ≠ poster ≠ disburser, with a compliance report
  • Configurable multi-level approval engine live on 17 business objects
  • Double-entry GL — balanced postings, period locks, dimensions, multi-currency + FX revaluation
  • Schema-per-tenant isolation — supports the SoW's data-ownership and handover requirements
Verification ◇ Every item above carries file-level evidence in the underlying audit (00-program/audits/PRAL-SOW-GAP-ANALYSIS-2026-07-31.md). These capabilities are also where AugmentERP differs most from generic ERP baselines: they exist in code, not in a localization backlog.

Gap analysis

Four modules have no usable implementation.

Together these carry ~30% of the SoW's functional weight and set the cost and timeline of any compliant response. Two have internal design artifacts; two do not.

+
01 · Budgeting 0%
No budget entity, no enforcement, no utilization view anywhere in code. Budgetary control is the central discipline in a state-owned entity's finance function.

Annual budgeting, revisions, budget-availability control and utilization monitoring are all absent: no entity, no table, no handler, no UI, and no budget check in any posting or approval path.

Implementation note ◇ The posting engine already gates every ledger write (period locks, dimensions, control accounts); budget enforcement can be added at that existing gate. Estimated L, not XL.
+
02 · Procurement ~20%
PO → GRN → three-way match is implemented. Everything upstream of the PO is absent. The term “PPRA” does not occur anywhere in the repository.
  • Implemented — purchase orders, goods receipts with GR/IR accrual, vendor master, tolerance-gated three-way match, AP dashboards.
  • Absent — procurement planning, requisitions (internal spec exists, zero code), RFQ, comparative statements, bid evaluation, contracts, vendor scorecards, PPRA rules.
Implementation note ◇ The requisition/PO spec (PROC-FR-*) exists internally; RFQ, bid evaluation and the PPRA pack have no design and must be scoped from the client's applicable rules.
+
03 · Inventory 0%
No code and no design documents. No item master, stock ledger, warehouse, barcode, valuation or counts.

The only inventory trace is an accounting one: the GRN posts a GL accrual to an account labelled “inventory” — no perpetual stock ledger is written. Unlike procurement and fixed assets, there is no BRD, spec, ADR or mockup. Design starts from zero.

+
04 · Fixed assets 0% code
Zero code. A 1,324-line internal BRD with ~40 numbered requirements exists — depreciation math, SoD matrix, JE templates — which reduces design risk but not build effort.
  • Registration & tagging (barcode/RFID), capitalization from AP/CIP with dual-auth thresholds.
  • Depreciation engine — SL, DDB with switchover, UOP; three conventions; idempotent runs; a parallel tax book.
  • Transfers, physical count sessions, six disposal types, standing report set.
Scope note ◇ Asset maintenance records are deferred in the internal BRD as a separate EAM concern — the SoW lists them, so this must be scoped explicitly in the requirements workshop.
Doc/code drift ◇ Internal module specs mark implemented procurement entities (Vendor, PO, GRN, Bill) as “planned” — the code is ahead of the documentation. This audit, not the specs, is the source of truth for build status.

Partial implementations

Modules that work today, and where they fall short of the SoW.

The 60–75% modules are functional but miss specific SoW requirements. The right column lists the concrete misses; the most consequential are in bold.

AreaWorking todayMissing against the SoW
Finance · 66% Double-entry GL with hash-chained ledger · full AP incl. 3-way match · AR incl. collections · bank reconciliation · fiscal close · multi-currency. Budgets, cash-flow statement, profit centers, ad-hoc reports · vendor withholding tax (payroll WHT only; PRAL is itself a withholding agent) · advances · cost-center master.
Payroll · 70% Paisa-exact engine · FBR slabs + §149 · EOBI/PF/OPD · SoD-gated runs · emailed PDF payslips · tax certificates · attendance/LOP feed. Bank transfer files · arrears/retro engine (the Correction run type's input is never populated) · final settlement (frontend mock only) · general loans & advances · batch bonus/Eid on the live engine.
Workflow · 75% Configurable multi-level chains on 17 objects · inbox + realtime + email fan-out · immutable decision audit. Delegation · true escalation (SLA breach is reported, never escalated) · linear chains only — no amount-band or parallel routing.
BI & DMS · 33 / 70% HR / manager / finance dashboards · finance drill-through · grid export (xlsx/CSV/PDF) that strips sensitive columns · document RBAC + signed URLs. CEO/CFO dashboards · ad-hoc report builder (an explicit SoW requirement) · document versioning beyond policies · cross-silo search.
Security · 70% Action-level RBAC (~950-line catalog) · tamper-evident audit · step-up re-auth · session revocation · finance SoD matrix. MFA and SSO (symmetric JWT only — Entra ID is a build, not configuration) · password complexity/history · at-rest encryption beyond platform default · productised backup with tested RPO/RTO.
Migration & integration · 45% Finance cutover wizard with TB reconciliation · CoA CSV import · bank-statement import profiles · 88-controller versioned REST API. Employee/HR bulk import · 5-year historical tooling · outbound bank files (ISO 20022) · webhook framework · email is AWS SES only (no SMTP/Graph option).

Effort estimate

Work required to close the gaps.

S ≤ 1 wk · M ≈ 2–4 wk · L ≈ 1–2 mo · XL ≈ 2–4+ mo — single squad, on the current architecture. Tier 1 items are prerequisites for a compliant response; Tier 2 affects evaluation scoring; Tier 3 is contractual posture.

TierBuild itemScope noteSize
T1Budget managementAnnual budget → revisions → availability control at the posting-engine gate → utilization reporting.L
T1Procurement funnel + PPRAPlan, requisition (spec exists), RFQ, comparative statements, bid evaluation, PO approval, contracts, vendor scorecards, PPRA rules.XL
T1Fixed assetsRegister → capitalization → depreciation engine → transfers → counts → disposals → reports. Design risk reduced by the existing BRD.XL
T1InventoryItem master, multi-location stock ledger, movements, counts, reorder, valuation, consumption. Greenfield including design.XL
T1Bank payment filesPayroll salary-transfer + AP payment-run export — per-bank CSV profiles first (mirrors the existing import-profile pattern), then ISO 20022.M
T2Payroll completionArrears/correction wiring, server-side final settlement, general loans with recovery schedules, batch bonus/Eid. The engine inputs are already modelled.M–L
T2Vendor withholding taxSection-wise rate master, deduction at payment, vendor WHT certificates, FBR filing. Reuses the payroll WHT filing pattern.M
T2Self-service BIAd-hoc report builder honoring the sensitive-column registry · CEO/CFO/procurement dashboards with KPI targets.L + M
T2Security & workflow hardeningEntra ID SSO + MFA + configurable password policy · approval delegation + escalation sweeper · HR bulk import + historical-migration tooling.M–L each
T3Ops & portabilityProduction pipeline + IaC (in-country / on-prem option), SLA monitoring evidence, automated backup with tested RPO/RTO, published OpenAPI, SMTP/Graph email, malware scanning, audit retention.S–M each

Risks

Commercial and delivery risks.

Items that change the price or the plan if left unexamined before a response is submitted.

Commercial

Contract obligations not yet supported by the product

  • 99.5% SLA with penalties, 5-year support — no production ops tooling, DR drills or SLO evidence exist; an ops-hardening workstream must be costed before these terms are accepted.
  • 5-year historical migration — not possible with current tooling; the realistic default is summarized balances plus a read-only legacy archive, with full journal migration as a separately priced option.
  • Hosting & residency — deployment artifacts are GCP-only with no IaC; PRAL operates its own data centers and the SoW's “public, private or hybrid” wording permits a private/on-prem demand. Needs confirmation before pricing.
  • PPRA rules — the federal Public Procurement Rules 2004 apply; exact rules and thresholds must be pinned in the requirements workshop the SoW mandates.

Delivery

Execution risks in closing the gaps

  • Four XL/L modules — sequencing matters: fixed assets has a ready BRD; inventory requires a design phase before build.
  • Two payroll stacks coexist in the repository — all gap-closing work must target the live FinPayroll engine, not the deprecated legacy module.
  • EOBI seed data carries a confirm-before-go-live TODO — rates must be verified against the current EOBI Act table during UAT.
  • Evaluator scrutiny — PRAL's evaluators develop software; claims in the response should be limited to what can be demonstrated in code.

Open items

Questions that change the estimate.

The analysis stands without these; each answer moves the price or the plan.

1 · Hosting & residency
Cloud vs PRAL's own data centers; data-residency constraints. Determines the ops workstream and the SLA that can responsibly be signed.
2 · PPRA specifics
Applicable rules, thresholds and e-procurement expectations — turns the PPRA work from unscoped design into a bounded build.
3 · Historical migration
Whether summarized balances plus a read-only archive satisfy the 5-year requirement, or full journal migration is expected.
4 · Phasing
Whether PRAL will accept phased delivery — configured existing modules first, net-new modules against the workshop-driven FRS.
5 · Integration targets
Which banks (and file formats), which email infrastructure, and which existing PRAL applications require APIs at go-live.
Recommendation ◇ A phased response matches the gap profile: Phase 1 configures what exists — finance core, payroll, workflow, security — demonstrated live; Phase 2 builds budgeting, procurement/PPRA, inventory and fixed assets against the workshop-driven FRS the SoW itself mandates. The statutory compliance spine and the tamper-evident audit trail are the most defensible claims available for the response.
1 / 10