---
title: "IFS UAT Test Tracker Template for IFS Cloud Projects"
date: 2026-10-12
description: "Copy-ready IFS UAT test tracker template for IFS Cloud: 16 columns, eight example procurement, sales and finance rows, severity and go/no-go rules."
author: "Dariusz Myśliwiec"
intro_image: "https://ifs-erp.consulting/images/articles/uat-test-tracker-template-ifs-cloud-en-0bba3321.webp"
fulltext_image: "https://ifs-erp.consulting/images/articles/uat-test-tracker-template-ifs-cloud-en-0bba3321.webp"
categories:
  - name: "How IFS Cloud ERP Transforms Business Operations Supply Chain AI and Legacy System Migration"
    url: "https://ifs-erp.consulting/ifs-cloud.md"
tags:
  - name: "IFS Cloud"
    url: "https://ifs-erp.consulting/tags/ifs-cloud.md"
  - name: "UAT"
    url: "https://ifs-erp.consulting/tags/uat.md"
  - name: "Go-Live"
    url: "https://ifs-erp.consulting/tags/go-live.md"
  - name: "Testing"
    url: "https://ifs-erp.consulting/tags/testing.md"
  - name: "Best Practices"
    url: "https://ifs-erp.consulting/tags/best-practices.md"
---

# IFS UAT Test Tracker Template for IFS Cloud Projects

![IFS UAT Test Tracker Template for IFS Cloud Projects](https://ifs-erp.consulting/images/articles/uat-test-tracker-template-ifs-cloud-en-0bba3321.webp)

An IFS UAT test tracker is a register with one row per business scenario that proves business users tested and accepted an IFS Cloud solution or release upgrade. The template below has 16 columns, eight filled-in supply chain and finance rows, severity levels, go/no-go rules and a CSV block you can paste into Excel.

The structure splits ownership three ways: the business owns scenarios and sign-off, the project owns defects and cadence, and the IFS consultant owns fixes and retest readiness. The sections below follow that split.

## Key takeaways

 
- One row equals one scenario, executed by a business user logged in with the permission set of the production role, never an administrator user.
- Two columns decide what UAT can prove and are easy to leave out: **permission set used** and **sign-off**; without them UAT cannot show that access design and acceptance were tested.
- Severity needs four levels and a written rule per level; an open S1, or an S2 in a critical process without written acceptance, means no-go.
- A daily 30-minute triage keeps the defect log honest: every defect gets a severity, an owner and a target build before the meeting ends.
- The IFS Scope Tool is reported to produce manual Test Trackers per scenario; no public IFS documentation of the function was found, so confirm the format with your Solution Architect before building on it.

## What is an IFS UAT test tracker and who owns each part?

 A UAT test tracker is the single list of scenarios, results and approvals that a business uses to decide whether to go live. It sits between the process design and the go-live decision, so each part has one accountable owner, listed below. For how UAT fits the IFS implementation phases, see [Definition of UAT based on the IFS implementation methodology](https://ifs-erp.consulting/ifs-cloud/uat-ifs-cloud); for the wider test strategy, see [IFS Testing: A Technical Perspective for Implementation Success](https://ifs-erp.consulting/ifs-cloud/ifs-testing).

 
| Part of the tracker | Owner | What they do |
| --- | --- | --- |
| Scenario list and expected results | Business process owner | Confirms the scenarios cover the process and signs the expected result as correct |
| Execution and evidence | Key users and expert users | Run the steps with their own production permission set, record the actual result and attach evidence |
| Defect log and severity | Test lead (project side) | Opens the defect, proposes severity, runs the daily triage and keeps the counts honest |
| Fix and retest readiness | IFS consultant or partner, developer for CRIMs | Resolves configuration and custom-code defects and tells the test lead which build or release carries the fix |
| Permission set column | Security or permission owner | Keeps the mapping from business role to permission set and confirms testers are not using an admin user |
| Sign-off | Business process owner, then project sponsor | Signs per process area once exit criteria are met; the sponsor signs the go decision |

 The IFS application has its own meaning of "role": a permission set grants access to pages and actions, while the UAT role is the job a person does in the process. The tracker maps one to the other in two columns, so a failed scenario can be traced either to the process or to the access design. The segregation-of-duties side is covered in [permission sets and segregation of duties](https://ifs-erp.consulting/ifs-cloud/permission-sets-and-segregation-of-duties) and [precision permission set configuration](https://ifs-erp.consulting/offer/precision-permission-set-configuration-for-ifs-cloud).

## What does a copy-ready IFS Cloud test tracker template contain?

 The template has 16 columns, split here into a design block (filled before the cycle) and an execution block (filled during it), joined by the ID. Use the column guide first, then the example rows.

 
### Column guide

 
| Column | What goes in it | Who fills it |
| --- | --- | --- |
| ID | Stable key such as P2P-01. Never renumbered, so defects and sign-off keep pointing at the same row | Test lead |
| Process area, Scenario | The business process and one testable outcome, written as a sentence a key user recognises | Process owner |
| Business role, Permission set used | The job role and the exact permission set the tester logs in with | Process owner, permission owner |
| Test data | The concrete records needed (part, supplier, customer, amounts), so a second tester can repeat the run | Key user |
| Steps, Expected result | Numbered actions and the observable result, including statuses and postings where they matter | Key user, IFS consultant |
| Actual result, Status | What happened, and one of: Not started, In progress, Passed, Failed, Blocked, Passed on retest, Deferred (agreed) | Tester |
| Defect ID, Severity | Reference to the defect log and S1 to S4 from the severity table below | Tester proposes, triage confirms |
| Tester, Date | Name and date of the run; for a retest, of the latest run | Tester |
| Retest | Build or release in which the fix was verified, and the result | Tester |
| Sign-off | Name and date of the process owner who accepts this scenario or the process area | Process owner |

 
### Design block with example rows

 The permission set names are placeholders for your own naming. Replace the expected results with your configured behaviour: authorization rules, routing templates and ownership transfer points differ per company, and status names should be checked in your release.

 
| ID | Process area | Scenario | Business role | Permission set used | Test data | Steps | Expected result |
| --- | --- | --- | --- | --- | --- | --- | --- |
| P2P-01 | Procurement | Requisition above the authorization rule limit is routed to the approver | Requisitioner, then Department manager | ZREQ_REQUESTER and ZREQ_APPROVER (customer-defined) | Requisition for a stocked part, value above the rule limit | 1 Create and release the requisition. 2 Check that authorization is required for it. 3 Approver authorizes the requisition lines | Requisition shows as authorized after the approver acts (check the exact status names in your release). A line that still needs authorization cannot be converted to a PO |
| P2P-02 | Procurement | Authorized requisition line converts to a purchase order | Buyer | ZPUR_BUYER (customer-defined) | Authorized line from P2P-01, supplier with a valid price | 1 Convert the requisition line to a purchase order. 2 Release the order | PO is created for the right supplier, quantity and price. If a PO authorization rule applies, the order cannot proceed until it is authorized (check the exact status names in your release) |
| P2P-03 | Procurement | Order the buyer is not allowed to authorize stays blocked | Buyer | ZPUR_BUYER (customer-defined) | PO above the buyer limit in your SoD matrix | 1 Log in as the test buyer. 2 Try to release and authorize the PO | Release is stopped until the routing template approver authorizes, and the buyer cannot approve their own order, as designed in your SoD matrix |
| P2P-04 | Inventory receipt | Partial receipt against a purchase order | Warehouse operator | ZINV_RECEIVER (customer-defined) | PO line for 100 pcs, receive 60 | 1 Register the receipt of 60 pcs. 2 Check the PO line status. 3 Check where the stock sits | Line shows 60 received, 40 open. Inventory postings follow your configured ownership transfer point |
| P2P-05 | Accounts payable | Supplier invoice matches the purchase order receipt | AP clerk | ZFIN_AP_CLERK (customer-defined) | Receipt from P2P-04, invoice with a 2 percent price difference | 1 Enter the supplier invoice. 2 Match it to the receipt. 3 Record the price difference | Invoice is matched at receipt or line level, and the price difference is shown and posted as configured |
| P2P-06 | Accounts payable | Payment proposal selects only authorized invoices | AP manager | ZFIN_AP_MANAGER (customer-defined) | One authorized and one unauthorized invoice for the same supplier | 1 Generate a payment proposal for the date interval. 2 Check the selection. 3 Process the proposal as in your payment procedure | Only the authorized invoice is selected |
| O2C-01 | Sales | Customer order reservation respects the credit limit | Sales coordinator | ZSAL_COORDINATOR (customer-defined) | Customer close to the credit limit, stocked part available | 1 Enter a customer order line. 2 Reserve the order. 3 Read the credit check message | Reservation follows the credit limit and advance invoice rules configured for the customer |
| INV-01 | Inventory | Stock reservation shows on the part in stock | Planner | ZINV_PLANNER (customer-defined) | Part with two stock locations | 1 Reserve a customer order line. 2 Open the part in stock and check the reservation | Reservation is visible on the stock record and quantity available is reduced |

 
### Execution block, as it looks before the cycle starts

 
| ID | Actual result | Status | Defect ID | Severity | Tester | Date | Retest | Sign-off |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| P2P-01 |  | Not started |  |  |  |  |  |  |
| P2P-02 |  | Not started |  |  |  |  |  |  |
| P2P-03 |  | Not started |  |  |  |  |  |  |
| P2P-04 |  | Not started |  |  |  |  |  |  |
| P2P-05 |  | Not started |  |  |  |  |  |  |
| P2P-06 |  | Not started |  |  |  |  |  |  |
| O2C-01 |  | Not started |  |  |  |  |  |  |
| INV-01 |  | Not started |  |  |  |  |  |  |

 
### Paste into Excel

 The block below uses a semicolon as the delimiter. Paste it into column A, then use Data, Text to Columns, Delimited, and tick Semicolon. Add one row per scenario and keep the IDs stable.

 
```
ID;Process area;Scenario;Business role;Permission set used;Test data;Steps;Expected result;Actual result;Status;Defect ID;Severity;Tester;Date;Retest;Sign-off
P2P-01;Procurement;Requisition above the authorization rule limit is routed to the approver;Requisitioner, then Department manager;ZREQ_REQUESTER and ZREQ_APPROVER (customer-defined);Requisition for a stocked part, value above the rule limit;1 Create and release the requisition. 2 Check that authorization is required for it. 3 Approver authorizes the requisition lines;Requisition shows as authorized after the approver acts (check the exact status names in your release). A line that still needs authorization cannot be converted to a PO;;Not started;;;;;;
P2P-02;Procurement;Authorized requisition line converts to a purchase order;Buyer;ZPUR_BUYER (customer-defined);Authorized line from P2P-01, supplier with a valid price;1 Convert the requisition line to a purchase order. 2 Release the order;PO is created for the right supplier, quantity and price. If a PO authorization rule applies, the order cannot proceed until it is authorized (check the exact status names in your release);;Not started;;;;;;
P2P-03;Procurement;Order the buyer is not allowed to authorize stays blocked;Buyer;ZPUR_BUYER (customer-defined);PO above the buyer limit in your SoD matrix;1 Log in as the test buyer. 2 Try to release and authorize the PO;Release is stopped until the routing template approver authorizes, and the buyer cannot approve their own order, as designed in your SoD matrix;;Not started;;;;;;
P2P-04;Inventory receipt;Partial receipt against a purchase order;Warehouse operator;ZINV_RECEIVER (customer-defined);PO line for 100 pcs, receive 60;1 Register the receipt of 60 pcs. 2 Check the PO line status. 3 Check where the stock sits;Line shows 60 received, 40 open. Inventory postings follow your configured ownership transfer point;;Not started;;;;;;
P2P-05;Accounts payable;Supplier invoice matches the purchase order receipt;AP clerk;ZFIN_AP_CLERK (customer-defined);Receipt from P2P-04, invoice with a 2 percent price difference;1 Enter the supplier invoice. 2 Match it to the receipt. 3 Record the price difference;Invoice is matched at receipt or line level, and the price difference is shown and posted as configured;;Not started;;;;;;
P2P-06;Accounts payable;Payment proposal selects only authorized invoices;AP manager;ZFIN_AP_MANAGER (customer-defined);One authorized and one unauthorized invoice for the same supplier;1 Generate a payment proposal for the date interval. 2 Check the selection. 3 Process the proposal as in your payment procedure;Only the authorized invoice is selected;;Not started;;;;;;
O2C-01;Sales;Customer order reservation respects the credit limit;Sales coordinator;ZSAL_COORDINATOR (customer-defined);Customer close to the credit limit, stocked part available;1 Enter a customer order line. 2 Reserve the order. 3 Read the credit check message;Reservation follows the credit limit and advance invoice rules configured for the customer;;Not started;;;;;;
INV-01;Inventory;Stock reservation shows on the part in stock;Planner;ZINV_PLANNER (customer-defined);Part with two stock locations;1 Reserve a customer order line. 2 Open the part in stock and check the reservation;Reservation is visible on the stock record and quantity available is reduced;;Not started;;;;;;```

## How do you define defect severity and go/no-go rules for UAT?

 Severity must describe the business effect, not the effort to fix, and each level needs a rule that decides what happens at go-live. The values below are starting points to agree with the steering group before cycle one; they are working practice, not an IFS standard.

 
| Severity | Definition | Rule for go-live |
| --- | --- | --- |
| S1 Blocker | A business process cannot be completed and there is no workaround, or a posting, payment, tax or authorization result is wrong | Must be fixed and retested. Any open S1 means no-go |
| S2 Major | The process completes only through a manual, error-prone or temporary workaround | Fixed, or accepted in writing by the process owner with workaround, owner and fix date. No open S2 in a critical process without that acceptance |
| S3 Minor | Wrong label, layout, report format or message with a trivial workaround | May go live. Logged with a target release |
| S4 Change request | Behaviour matches the agreed design but the user wants something else | Not a defect. Goes to the change backlog and is not counted in exit figures |

 
### Entry and exit criteria

 
| Gate | Criterion (starting values to agree with the steering group) |
| --- | --- |
| Cycle entry | Build deployed and smoke-tested; tester accounts exist with the production permission sets; test data loaded and checked; scenarios approved by process owners; defect log open |
| Cycle exit | All critical-process scenarios executed; no open S1; every open S2 has a written decision; every S1 and S2 fix retested; first-pass rate and blocked count reported |
| Go-live recommendation | Two consecutive clean passes of the critical processes in the final cycle; zero open S1; no unaccepted S2; training material updated for each accepted workaround; every process area signed |
| No-go triggers | Any open S1; any unaccepted S2 in a critical process; a critical scenario not executed; a fix delivered without retest; a tester signing off a scenario they did not run |

 The go/no-go table is also the agenda of the readiness checkpoint in your [governance cadence](https://ifs-erp.consulting/data-governance/governance-cadence), where the sponsor sees counts per severity and per process area instead of a percentage of tests done. Exit criteria are easier to agree when they are written into the test strategy: [Test Strategy Template (IDK-17)](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/17-test-strategy) has entry and exit criteria per test cycle, and [SAT and ORT Test Script and Sign-off Template (IDK-18)](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/18-sat-ort-test-script-and-signoff) carries the script, the defect log and the signed completion report. The same reasoning applies to the cutover rehearsal: [go-live is a load test](https://www.ifs-erp.com/en/blog/go-live-is-a-load-test) explains why the go/no-go criteria are written before the rehearsal, not during it.

## How do you run an IFS Cloud UAT cycle?

 A UAT cycle is a fixed window in which the same scenario list is executed on a stable build, triaged daily and closed with signed evidence. The sequence:

 
1. **Check the entry criteria.** The build is deployed, testers can log in with the production permission sets, the test data from the tracker exists, and the scenarios are approved. A cycle that starts without this burns its first days on environment defects.
2. **Assign scenarios by role, not by person.** Every row has a named tester and a backup. A scenario nobody owns shows as Not started in the report on day one, which is the point.
3. **Hold a 30-minute triage every day at the same time.** Attendees: test lead, IFS consultant, a developer if CRIMs are involved, and one key user per process. Each new defect is classified as configuration, custom code, data, permission, training or change request, and gets a severity, an owner and a target build.
4. **Freeze the build between fix drops.** Fixes arrive in named drops. A tester retests only against a drop, and the Retest column records which one.
5. **Retest the fix and the neighbours.** Every S1 and S2 fix is retested; scenarios that share the object or permission set with the fix are re-run.
6. **Collect evidence while testing.** Per scenario keep the document numbers created (order, requisition, voucher), a screenshot of the result, the user and permission set, the date and the build.
7. **Close the cycle with sign-off.** The process owner reviews the failed, blocked and deferred rows, accepts or rejects each, and signs the process area. The test lead publishes the exit figures against the criteria above.

 For upgrades, add the readiness view from [IFS Cloud upgrade readiness](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-upgrade-readiness) and the user-side checks in [how to assess whether business users are prepared for an ERP upgrade](https://ifs-erp.consulting/ifs-cloud/prepared-for-an-erp-upgrade). Automating the regression part is discussed in [Rethinking test automation for IFS Cloud](https://ifs-erp.consulting/ifs-cloud/rethinking-test-automation).

## Which environment and test data should UAT use, and can you create a test company in UAT?

 UAT needs an environment that behaves like production, with data that business users recognise and a company set up the way production will be. A separate test company in the UAT environment is a workable technique for tests that post or delete data, and a weak basis for acceptance of the configuration that the live company will run.

 
- **Company-specific configuration.** Authorization rules, routing templates, posting control and ownership transfer points live per company or per part. A test company only proves them if you copy them, so verify what a copy actually carries over before relying on it. Nothing on docs.ifs.com that forbids a test company in UAT was found; this guidance is working practice.
- **Test data for IFS-provided environments.** An IFS reply on the Community confirms that on-demand environments include generic pre-defined test data and no customer-specific data, see [the thread](https://community.ifs.com/upgrades-updates-81/is-test-data-included-when-creating-an-on-demand-environment-in-ifs-cloud-40201). For a release upgrade, a Community answer describes the upgrade being done in a separate non-production environment with a copy of customer data, see [the 24R2 to 26R1 thread](https://community.ifs.com/framework-experience-infrastructure-cloud-integration-dev-tools-50/ifs-cloud-24r2-to-26r1-upgrade-process-questions-about-lifecycle-database-migration-and-testing-68331).
- **Test Data Management.** The IFS Lifecycle documentation on docs.ifs.com has a Test Data Management section; check it for the current options, and confirm any licensing with IFS before planning around it.
- **Migrated data.** If UAT uses migrated data, the quality of the migration decides the quality of the result. See [data migration silent killers in FNDMIG and DMM](https://ifs-erp.consulting/ifs-cloud/data-migration-silent-killers-fndmig-dmm) and [IFS DMM step by step](https://ifs-erp.consulting/ifs-cloud/ifs-dmm-step-by-step).
- **Personal data.** If production copies are used, decide who may see which data before testers get access. No documented masking feature was found, so treat masking as a customer decision.

 Write the test data into the tracker row. If the scenario needs "a customer near the credit limit", name the customer ID, so the run can be repeated and the failure reproduced.

## What does the IFS Scope Tool give you, and what must you build yourself?

 The Scope Tool gives you the process hierarchy down to scenario level, and according to a Community reply it feeds a Test Tracker in which each scenario is one test case. It does not give you the severity rules, the cycle cadence, the permission-set mapping or the sign-off evidence; those come from your project.

 
| Topic | What the sources state | What you build |
| --- | --- | --- |
| Scenario list | A Community reply says the Scope Tool models business processes to scenario level and drives Test Tracker creation, one scenario per test case, as manual tests and not automated scripts. See [the Scope Tool thread](https://community.ifs.com/framework-experience-infrastructure-cloud-integration-dev-tools-50/ifs-scope-tool-2c8-49537). | Review every scenario with its process owner; add integration, authorization and negative scenarios. |
| Tracker format | The same reply mentions scenario sheets, overview sheets and pass/fail colouring. No public docs.ifs.com page with the menu path, column layout or export steps. | Compare the exported file with the 16 columns above; add the missing ones, typically permission set, severity, retest and sign-off. Ask the Solution Architect who maintains your Scope Tool. |
| Upgrade test material | No public statement was found that IFS supplies business test scripts for a customer release upgrade. The Community upgrade thread lists functional, regression, integration and reporting validation, and mentions no IFS test pack. | Derive the upgrade scope from your live processes, your CRIMs and the release notes; own the scenario list. |
| Automation | The IFS Developer Portal lists Script-A-Rest for scripting IFS Cloud functionality through its REST APIs. See [IFS Developer Portal](https://developer.ifs.com/). | Decide which regression scenarios deserve scripts; the tracker keeps the manual UAT evidence either way. |
| Defects and sign-off | Not described in the sources reviewed. | Defect log, severity rules, triage cadence, evidence and signatures, as in this article. |

 If you want a tool instead of a spreadsheet, the choice is between the Scope Tool export, a spreadsheet like the one above and a third-party test management product. Whatever you choose, keep the same column set, so evidence survives a change of tool.

## IFS UAT test tracker: frequently asked questions

 ### What is an IFS UAT test tracker?

 An IFS UAT test tracker is a register with one row per business scenario that records who tests it, with which permission set and data, what was expected, what happened, the defect and severity, the retest and the sign-off. In an IFS Cloud project or release upgrade it is the evidence that business users, not consultants, accepted the solution.

 ### Can the IFS Scope Tool generate a test tracker?

 According to a reply in [the Scope Tool thread on the IFS Community](https://community.ifs.com/framework-experience-infrastructure-cloud-integration-dev-tools-50/ifs-scope-tool-2c8-49537), yes: the Scope Tool drives the creation of Test Trackers in which each scenario becomes one test case, and these are manual test lists, not automated scripts. No public docs.ifs.com page describes the function or its exact output, so ask the IFS Solution Architect who maintains the Scope Tool for your project to export it.

 ### Is it acceptable to create a test company in the IFS Cloud UAT environment?

 A test company in UAT is acceptable for isolated or destructive tests, and it is a poor basis for acceptance of company-specific configuration such as authorization rules, posting control and number series. If a test company is created by copying another, verify what the copy carries over before relying on it. Run the critical scenarios in the company that mirrors production.

 ### Who should run UAT in IFS Cloud?

 Business key users and expert users run UAT, each logged in with the permission set of the production role they represent. Consultants prepare data, triage defects and fix configuration, but they do not execute or sign off the business scenarios. The process owner signs per process area.

 ### What should block a go-live decision in UAT?

 Any open S1 defect, any S2 defect in a critical process without a written acceptance, a critical scenario that was not executed, or a fix delivered without a retest. Agree these rules before the first cycle starts so that the decision is not negotiated under deadline pressure.

 ### Does IFS provide UAT test scripts for an upgrade?

 No public statement was found that IFS supplies ready-made business test scripts for a customer release upgrade. A community thread on a 24R2 to 26R1 upgrade describes functional, regression, integration and reporting validation on a separate non-production environment with a copy of customer data and mentions no IFS test pack, so plan to own the scenario list.

## Sources

 
- [IFS Scope Tool - 2C8, IFS Community](https://community.ifs.com/framework-experience-infrastructure-cloud-integration-dev-tools-50/ifs-scope-tool-2c8-49537)
- [Is test data included when creating an on-demand environment in IFS Cloud, IFS Community](https://community.ifs.com/upgrades-updates-81/is-test-data-included-when-creating-an-on-demand-environment-in-ifs-cloud-40201)
- [IFS Cloud 24R2 to 26R1 upgrade process, IFS Community](https://community.ifs.com/framework-experience-infrastructure-cloud-integration-dev-tools-50/ifs-cloud-24r2-to-26r1-upgrade-process-questions-about-lifecycle-database-migration-and-testing-68331)
- [IFS Developer Portal, Script-A-Rest](https://developer.ifs.com/)

## About the author

 **Dariusz Myśliwiec**: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.

 **Selected clients:** Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

 For the end-to-end project view, see the [IFS Cloud ERP implementation guide](https://ifs-erp.consulting/ifs-cloud/ifs-cloud-erp-implementation-guide). To set up a tracker and run UAT cycles on your project, [book a 30-minute call](https://ifs-erp.consulting/contact).

 IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.