After Delivery: Testing, Acceptance and the Free-Fix Period When Nilex Hands Over a System

When Nilex delivers a system, you have 14 days to test it and report any error; we fix what you report and deliver again. After you accept the work, we fix any error in the delivered work free of charge for another 30 days. Anything outside the agreed scope is a change request, quoted and agreed before it is done, and after the 30 days support and maintenance continue under a support plan or are quoted separately.

Those numbers only protect you if you use them. Many companies receive a system, get busy, and discover a problem in the invoice screen three months later, when the question is no longer "is this an error?" but "who pays?". This guide explains the timeline, how to test properly in the first two weeks, and how to tell an error we fix from a change we quote.

Key takeaways

• Delivery starts a 14-day window to test and report errors; each reported error is fixed and delivered again.
• For 30 days after acceptance, errors in the delivered work are fixed free of charge.
• An error is the system not doing what was agreed; a change request is something new or different, quoted first.
• Test with your real data, every role and every printed document, not just the main screen.
• Report through the client portal, one problem per request, with a screenshot.

The handover timeline at a glance

The full wording is in our Terms of Service. Two related rules are worth knowing: if a client cancels before acceptance, half of the amounts paid is refunded; after acceptance there is no refund. That is one more reason to test seriously before you accept. Payment schedules are covered in paying for a software project in installments.

Why the first 14 days matter most

A system is never tested as well as by the people who will use it. Developers test that each feature works; only your team can test that it works for your business, with your customers, your products, your exceptions and your habits. The 14 days are your chance to put real work through the system while the delivery is still fresh, and every error you report is fixed and delivered again.

If you are moving from spreadsheets, load or check a meaningful sample of your real data first. Our guide on moving data from Excel to an ERP explains how to prepare it, and how a custom ERP project runs covers testing with real data as a project phase.

A practical testing checklist

Split the work across the people who will use the system, and give each a list. A good list covers:

1. A full real day. Run one complete day of work end to end: for a workshop, from check-in to invoice; for a distributor, from order to delivery and collection; for a school, from attendance to the parent seeing it.
2. Every role. Log in as each kind of user, owner, branch manager, cashier, technician, sales rep, customer, and check they see what they should and nothing more.
3. Every document. Print each PDF the system produces, in Arabic and in English where relevant: invoices, receipts, statements, reports. Check names, totals, your logo and layout.
4. The numbers. Compare totals, balances and reports with what you calculate by hand for a few real cases.
5. The exceptions. Partial payments, returns, discounts, cancelled orders, a customer with two branches: the cases that cause trouble in your business.
6. The rules. Try to do what the system should block, such as selling something unavailable or skipping an approval, and confirm it stops you.
7. Devices. Use the screens on the phones and tablets your team actually uses.
8. Permissions and logs. Change something as one user and check it is recorded with who did it and when.

If you saw a demo before buying, go back to the scenarios you checked then; our article on how to evaluate a system before you buy it lists them.

Error or change request: where is the line?

The simplest test: does the system fail to do what was agreed? Then it is an error, and it is fixed. Do you want it to do something that was not agreed, or differently from what was agreed? Then it is a change request, quoted and agreed before it is built. The examples below are illustrative.

When something is unclear, report it anyway and describe it honestly. It is better to discuss a borderline case in week one than to argue about it later. The written quotation, which sets out the scope, is the reference both sides use.

How to report what you find

Use your client portal. Send a support request for an error and an edit request for a change, so the two are not mixed. Screenshots you attach to support requests are private: they are never public and are only shown after a permission check, which matters because screens often show customer names and balances.

• One problem per request.
• The screen, the record (an order number, a customer) and the user.
• What you expected and what happened.
• A screenshot of the whole screen.
• Whether work is blocked.

What happens after the 30 days?

After the free-fix period, support and maintenance are under a support plan or quoted separately. For the ready-made systems on our systems page, each plan says what it includes; the plans generally include the first year of hosting and support, and after that a yearly subscription covers hosting, support and updates. On systems such as the car protection centers and wholesale distribution systems, the FAQs list what the subscription covers: hosting, daily backups, security updates, new features and technical support.

Two things do not change after the free-fix period: you still own your data and can get a copy (for example Excel or CSV) on request, even after the agreement ends, and Nilex keeps the source code while you keep the licence to use the system. See your data stays yours.

Common mistakes during the testing window

• Only the manager tests. The cashier and the technician find different problems.
• Testing with invented data. "Test customer 1" never has the odd cases your real customers have.
• Collecting problems to send at the end. Report as you go, so fixes can start while you keep testing.
• Reporting on WhatsApp. Messages get lost; a request in the portal stays on record.
• Mixing new ideas with errors. Note new ideas separately as change requests so errors are not delayed.

How Nilex helps

• Choose a ready system on our systems page, such as the wholesale distribution system, and send the request form on its page. Every system is set up around your way of working and your team is trained before go-live.
• See the full journey in from request to go-live and the standards behind it in what makes a business system professional.
• For a system built from scratch, see our custom ERP service, or contact us.

Frequently asked questions

How long do we have to test after delivery?

14 days to test and report any error. We fix what you report and deliver again.

What is covered in the 30 days after acceptance?

Any error in the delivered work is fixed free of charge. New features or changes to the agreed scope are change requests and are quoted first.

What if we find an error after the 30 days?

Support and maintenance after that period are under a support plan or quoted separately. For ready-made systems, check the plan on the system page: the plans generally include the first year of hosting and support.

Can we cancel if the system does not suit us?

If you cancel before acceptance, half of the amounts paid is refunded. After acceptance there is no refund, which is why we recommend testing thoroughly in the 14 days.

Who should test on our side?

The people who will use the system every day, in every role, with real data and real documents, not only the manager who signed the contract.