ERP Requirements Consultant, Kuwait

A shared core and company annexes

The most useful decision in a Kuwaiti group specification is structural: what belongs to the group, and what belongs to one company. Without that split, every company's preferences end up as group requirements, and the vendor prices a system far heavier than any single company needs.

I organize the document like this:

• Group profile: legal entities, shareholding, outlets and warehouses, users by company and role, and current systems in each company.
• Group core: chart of accounts and dimensions, approval levels, purchasing and payment controls, intercompany charging, consolidation and owner reporting. These lines apply to every company and are owned by group finance.
• Company annexes: one short chapter per company with only what differs, such as progress billing for the contracting arm, royalty and sales reporting for franchised brands, or lease and service charge schedules for property.
• Statutory, precision and behavior requirements.
• Interfaces and data migration, per company.

Every requirement has a code that shows whether it is core or annex, an owner, a priority and a pass condition. That makes it simple to answer the question a group rollout always faces: which lines must be proven before the next company goes live. The interviews and process work that produce these lines are covered by my Kuwait ERP business analyst work; here the subject is the written specification and its use.

Statutory and precision lines without a VAT return

Kuwait has not introduced VAT, so the statutory chapter is shorter than in neighboring markets, but it is not empty. I draft it with group finance and your auditor or tax advisor, who confirms every line. I do not advise on tax or contributions; I turn confirmed obligations into requirements.

Lines that commonly appear include:

• Separate books for each legal entity, so the auditor can prepare statutory accounts and any contributions that apply to a company because of its legal form or listing, such as Zakat.
• Where your advisor confirms it applies, the ability to hold back part of a contractor payment until tax clearance is shown, and to track its release.
• For groups with foreign ownership or that belong to a large multinational, entity data your advisor needs for any income tax or group-level tax obligations.
• Salary payments produced as a bank transfer file in the layout your bank uses, with records the labor authority may ask for.
• Customer documents printed in Arabic, English or both as each company specifies, with Arabic wording approved by a bilingual reviewer you appoint.

The dinar is divided into fils, giving three decimals, so precision rules sit beside the statutory lines: amounts, unit prices, rounding, payment files, POS and ecommerce feeds, and exports must all hold three decimals, each with a test case. Tax-readiness lines, such as tax codes on items and parties, are marked should-have in case VAT is introduced. See the Kuwait ERP consultant page for wider context.

Behavior requirements for owners, outlets and sites

Behavior requirements, sometimes called non-functional requirements, say how the system must operate. In a Kuwaiti group several of them come from how the owners want control to work.

• Access by company: users see only the companies they work for, while group finance and owners see across all of them, with consolidated views that respect those rights.
• Owner approvals: payments or commitments above agreed levels route to a named owner, including on mobile, and cannot be bypassed by changing a user's role.
• Audit history: before and after values for bank details, prices, discounts and credit limits, plus a record of who approved what on behalf of whom.
• Hosting: the country or region holding live and backup copies of group data, and the points your lawyers and IT lead want settled, put to each vendor as written questions.
• Outlet and site connectivity: how retail outlets, restaurants or project sites keep trading or recording receipts when the link drops, and how data syncs afterwards.
• Load: peak transactions on busy trading days and at month-end, stated so testers can recognize them.

A vendor writing its own proposal has little reason to volunteer these commitments. Owning them in your specification is what carries them into the contract and the test plan.

Interfaces, group migration and traceability

Each connection gets its own block stating which systems talk, what flows each way, on what schedule, which side is the master and who is alerted when a transfer breaks. For Kuwaiti groups that can mean bank files for payments and statements, POS in outlets, delivery and ecommerce platforms, a franchisor's reporting system, HR and attendance tools, and sometimes property or contract management software.

Migration requirements are written per company: which customers, suppliers, items and assets move, what open business crosses over, from unpaid invoices to stock on hand, and which older years stay behind in an archive. Intercompany balances need their own requirement, because both sides must agree before any company goes live. A group that migrates in waves also needs a rule for how companies still on the old system trade with those already on the new one.

Priorities are set by owners and company managers on a plain scale from must have at go-live to not in this phase. Must-have lines in the core are traced into the demo scripts used during Kuwait ERP selection and into UAT cases for the first company, while annex lines are traced into the tests for their own wave. The fit result from the gap analysis sits in the same matrix.

Board sign-off, the contract and common gaps

In a family group, the specification needs approval from the people who actually decide. I prepare a short summary of scope, priorities and open questions for the family board or owners, then collect chapter sign-off from group finance and each company manager. The statutory chapter is signed only once the auditor's or advisor's confirmation is attached.

Bidders receive the approved text as an annex to the RFP and mark every line with their response, and the partner contract then refers to a locked copy of that same text. If the rollout runs in waves, each wave's statement of work refers to the core plus the relevant annex. After that, every change is a recorded request with a reason, an approver and its effect on cost.

Gaps that put Kuwaiti specifications at risk:

• No split between core and company needs, so the system is oversized for small companies.
• Three-decimal handling assumed rather than tested.
• Owner approvals left informal, so they happen outside the system.
• Intercompany balances missing from migration scope.
• No tax-readiness lines, so a future change means rework.

Running the tender is covered under ERP RFP consulting. You can also read about multi-entity setups on the multi-company ERP page and the Kuwait overview.