Code of Conduct for Buyers

Document control

1. Purpose and scope

Procura is a platform where buyers and suppliers run RFQs, sealed bids, awards and purchase orders. This Code sets the standard of conduct that every buying organisation on Procura accepts. The aim is plain: every RFQ is a real request, every award is a fair decision, and every record is a true one.

The Code of Conduct for Suppliers sets the standard for suppliers. The two documents work together. A buyer can expect from suppliers what the Supplier Code requires, and a supplier can expect from buyers what this Code requires.

This Code adds to the Terms of Use, the Buyer Agreement, the Acceptable Use Policy and the Data Processing Addendum. It does not replace them, and it does not reduce any duty under the law. The law always applies, and where the law is stricter than this Code, the law applies. Where a signed agreement between a buyer and a supplier, including a purchase order, deals with the same point, that agreement applies between them, but it never lowers the standards in sections 4 to 8 of this Code.

Where the buyer is a government entity, or is bound by the Government Tenders and Procurement Law, that law and the buyer's own rules apply as well. Procura is not the government procurement platform (Etimad) and does not replace it.

2. Who this Code binds

• The buying organisation, which accepts the Code through an authorised person.
• Every person who uses the organisation's Procura account or takes part in its procurement on Procura: requesters, procurement staff, approvers, evaluators, finance and accounts-payable staff, executives and administrators.
• Consultants, agents and others who act for the organisation in a Procura transaction.

The organisation is responsible for its people and for those it engages. Seniority is no exemption: the more influence a person has over a decision, the more closely this Code applies to them.

3. Principles

4. Conflicts of interest and disclosure

4.1 What it is

A conflict of interest exists when a personal, family, financial or business interest of a person at the buyer could affect, or could look as if it affects, a procurement decision. For example:

• a relative or close friend owns, manages or works for a supplier that is invited or bidding;
• the person, or a relative, holds a share in a supplier, or has a role in it, paid or unpaid;
• the person has been offered or has accepted a job, a loan or another benefit from a supplier; or
• the person has a private dispute with a supplier.

4.2 The duty to disclose and to step aside

A person who has a conflict declares it in writing to their manager and to the organisation's compliance contact before taking part in the RFQ, and in any case as soon as they learn of it. They then stand aside from the evaluation, the award recommendation and the approval, as far as the conflict reaches. The organisation records the declaration and who took over. An in-platform declaration step is planned, and until it exists the organisation keeps its own record. A disclosed conflict is not in itself a breach. A conflict that is hidden is.

4.3 What the platform already separates

The platform does not let the person who creates an RFQ or a purchase request approve it, and it picks approvers other than the requester. This helps, but it does not replace the duty to declare a conflict.

4.4 Suppliers connected to the buyer

A person at the buyer must not create, favour or invite a supplier in which they, or a relative, have an interest, unless the interest has been declared and the organisation has decided in writing that the supplier may take part.

5. Gifts, hospitality and improper advantage

5.1 What is always prohibited

• Bribery: asking for, accepting, offering or promising anything of value to influence or reward a decision, from or to a supplier, directly or through someone else.
• Kickbacks and secret commissions, and any arrangement to receive part of what is paid to a supplier.
• Facilitation payments: small unofficial payments to speed up or secure a routine action.
• Cash and anything like cash, such as vouchers, gift cards and loans.
• Favours: jobs, internships or contracts for relatives, donations to a person's chosen cause, or sponsorship, when they are asked for or are connected with a procurement.

5.2 Gifts and hospitality: the decision rule

Before accepting anything from a supplier, a person at the buyer asks five questions. If any answer is no, they decline.

1. Is every decision involving that supplier closed? No gift or hospitality while an RFQ, an award, a purchase order change, an invoice or a payment involving the supplier is open.
2. Is it modest and occasional, and ordinary courtesy such as a business meal or a small branded item?
3. Is it open? It is received on behalf of the organisation, and the person's manager can know of it.
4. Is it within the limit in the buyer's own policy? That limit is set by the buyer's own policy and recorded in the RFQ.
5. Would the person be comfortable if the other bidders and the auditors saw it?

Whatever the answers, entertainment and leisure trips, travel and lodging paid by a supplier, and cash or cash equivalents are not allowed. For visits to sites, factories or exhibitions, each side pays its own travel and lodging, unless the buyer's policy says otherwise and the buyer records it in the RFQ.

5.3 The buyer sets the limit, in every RFQ

The buyer sets the limit for gifts and hospitality under its own policy, and states it in each RFQ: a figure, or the word "none". Procura sets no amount. The person who creates the RFQ states the limit in the RFQ description. If the RFQ records no limit, the limit is none. A dedicated field with a reminder before the RFQ is published is planned.

5.4 If something improper is offered or asked

The person declines, writes down what happened, and reports it under section 13. A buyer's staff member who asks a supplier for a gift, a payment or a favour breaches this Code, and a supplier who is asked should report it.

6. Fair competition and sealed-bid integrity

6.1 What is prohibited

A person at the buyer must not:

• steer an RFQ to a chosen supplier, for example by writing a specification around one supplier or brand without a justification, or by inviting only suppliers chosen to lose;
• split a purchase into smaller ones to stay below an approval level;
• tell one bidder about another bidder's price, identity or terms, or give one bidder information that others do not have;
• let one supplier see, change or "match" its bid after seeing others, outside a final-offer round that is open to every eligible bidder;
• agree with a supplier, or with several, on prices or on who is to win; or
• ask a supplier to bid a price that the buyer has already agreed with another.

6.2 Sealed bids

Bids in a sealed RFQ stay closed until the stated opening time. A buyer's user does not try to see a bid early, does not ask anyone to show it, and does not pass bid contents to anyone who does not need them to evaluate. The platform shows prices only once the bids are open. If a buyer receives a bid or a price early by mistake, it stops, tells Procura, and does not use it.

6.3 Deadlines and extensions

A deadline is not shortened once the RFQ is published. An extension is given to every invited bidder at once, with the reason.

6.4 If a supplier makes an approach

The person declines, writes down what was said, and reports it under section 13.

7. Accurate information

7.1 What must be true

Everything a buyer gives to Procura or to a supplier must be true, complete and up to date: the organisation's name, commercial registration, VAT number and address, its authorised signatories and approval limits, and the content of each RFQ, namely the quantities, specification, delivery place and date, budget where stated, payment term, evaluation criteria and weights, and the dates.

7.2 What is prohibited

The buyer must not use another organisation's name or documents, open an account under a false name, give a supplier a false reason for a decision, or alter the requirements, criteria or weights after bids are received without telling every bidder in the same way.

7.3 Keeping records current

The buyer keeps its users, roles and approval limits up to date on the platform, and removes a person's access when they leave or change role. A buyer's administrator can deactivate the organisation's users.

7.4 Mistakes

A genuine mistake by a supplier is handled fairly. A buyer does not take deliberate advantage of an error, and where it finds one, it helps to correct it for the benefit of both sides, treating all bidders alike.

8. People, labour and safety

8.1 The buyer's own conduct

The buyer complies with the Saudi Labour Law and the related regulations for its own workforce, and meets the Saudization commitments that apply to its establishment under the Nitaqat programme. It does not use fictitious employment or any concealment arrangement, which the law prohibits.

8.2 What the buyer does not ask of suppliers

The buyer does not set a price, a deadline or a condition that can only be met by breaking labour or safety law, and does not ask a supplier to use forced, bonded or child labour, or to hold its workers' documents or wages.

8.3 Suppliers' people on the buyer's premises

Where supplier staff work on the buyer's premises or sites, the buyer provides the safety rules, equipment and induction that the law and the site require, and treats them with respect. It does not allow harassment, abuse or discrimination.

8.4 Fair access

The buyer keeps barriers to entry no higher than the need requires, so that capable small and medium businesses, including those led by women and young people, can compete. It does not set conditions that are not needed to exclude suppliers.

8.5 Guidance

This section follows the national labour framework, Vision 2030 objectives for national employment and empowerment, and the guidance of ISO 26000 on social responsibility. Procura does not require an ISO 26000 certificate.

9. Environment and community

Where a buyer uses sustainability or responsible-sourcing criteria, it states them in the RFQ, with their weight, so that every bidder can answer them. It does not use them in the evaluation if they were not stated.

Procura encourages, and does not require, local content: local sourcing, local employment, training and partnerships with small and medium businesses, in line with Vision 2030. A buyer that asks for local-content information says in the RFQ what it wants and how it will be weighed, and does not use it as an unstated reason to exclude a supplier.

10. Confidentiality and data protection

10.1 Suppliers' information

A supplier's prices, priced schedules, technical proposals, documents, certificates, bank details and other data given on Procura are confidential. The buyer uses them only for the procurement they were given for, and for the resulting purchase order, contract and payment. It limits access to the people who need them. It does not give them to another supplier or to a third party, other than its own advisers who are bound to confidentiality for that purpose. This duty continues after the RFQ ends. It does not apply to what the law requires the buyer to disclose.

10.2 Personal data

The names, telephone numbers and e-mail addresses of a supplier's staff that the buyer learns through Procura are used only for the transaction, and in line with the Personal Data Protection Law. They are not used for marketing or put on lists. A breach affecting personal data is reported without delay to Procura (security@procuraksa.com) and to the supplier concerned.

10.3 No scraping and no circumvention of controls

The buyer does not scrape or bulk-collect data from Procura, extract it by automated means, get round access controls or rate limits, or reverse-engineer the platform, as the Acceptable Use Policy provides. It does not use the supplier directory to contact suppliers for purposes unrelated to its own procurement.

10.4 Credentials

Each person uses their own account, tied to a named individual. Sign-in codes, sessions and Google sign-in are never shared or passed on. Suspected compromise of an account is reported at once to security@procuraksa.com.

10.5 Bank details

A supplier's bank details are used only to pay that supplier. A buyer does not act on a request, from anyone, to change them by e-mail or telephone. A change is made on the platform by the supplier, and it is held until Procura verifies it.

10.6 What the platform does to protect bids

Bids are encrypted when they are submitted. In the product, no Procura operator account has the permission to read bids, so in a sealed RFQ they stay closed until the opening time. Procura's own people may not look for another way round this. A buyer that believes it has happened reports it under section 13.

11. Conduct on the platform

11.1 Accounts

One account belongs to one person. Logins are not shared. Roles and approval limits match what each person is authorised to do.

11.2 No circumvention

Where a transaction began on Procura, whether as an RFQ, an invitation, a clarification, a bid, a quotation request or an award, the buyer carries it through on Procura, so that the bid, award, purchase order, delivery and invoice are recorded there. It must not move the transaction away from the platform in order to avoid the audit trail, its own approval controls, the sealed-bid process or the other bidders. This rule does not restrict dealings that did not begin on Procura.

11.3 No fake RFQs, bids or accounts

The buyer does not issue an RFQ it does not mean to act on, does not create or use accounts in the name of suppliers, and does not enter bids in a supplier's name or through a related party in order to move prices.

11.4 Awards and purchase orders

An award is followed by a purchase order as the RFQ stated. A buyer does not cancel an awarded RFQ without a recorded reason, does not change the terms after award unless the supplier agrees through a change order on the platform, and does not use the award to extract a concession that was not part of the RFQ.

11.5 Payment expectations

Every RFQ and every purchase order states the payment term. The buyer pays a valid invoice on that term. A valid invoice is a proper tax invoice that matches the purchase order and the goods receipt. Where part of an invoice is disputed, the buyer pays the undisputed part on time and says in writing, within the term, what is disputed and why. The buyer does not make payment depend on a discount, a rebate or a favour that was not agreed in the purchase order, does not hold payment back as leverage, and does not change the term after award. The term itself is the buyer's commercial decision. This Code sets no number of days.

11.6 Faults in the platform

A buyer that finds an error or weakness in Procura that gives an unfair advantage or exposes data stops, does not use it, and reports it to security@procuraksa.com. It does not test the platform's security without written permission.

11.7 Honest ratings

Ratings given to suppliers after an order is paid are honest and based on facts. Suppliers rate buyers on the clarity of the specification, the stability of the scope, responsiveness, conduct, payment timing and conduct in disputes, and this Code is the standard for those ratings.

12. Duties specific to buyers

12.1 Clear specifications

An RFQ states what is wanted in terms a supplier can price: quantities, specification, standards, delivery place and date, the evaluation criteria and their weights, the payment term, the gifts and hospitality limit, and the date and time of the deadline.

12.2 Equal information

Every invited bidder gets the same information at the same time. A question from one bidder is answered to all. The platform publishes every answer to every bidder and does not name the person who asked, and the buyer answers through that channel, not privately.

12.3 No reverse-engineering of suppliers' prices

The buyer does not use one supplier's price, cost structure or terms to build an alternative, to press another supplier, or to tell a third party what the first supplier offered. It does not ask bidders to disclose their cost breakdown beyond what the RFQ stated.

12.4 Evaluate on the stated criteria

Bids are evaluated against the criteria and weights stated in the RFQ, by evaluators who have declared any conflict. Scores are recorded. In a two-envelope RFQ the technical score is given before prices are opened and is not changed afterwards.

12.5 Award justification and feedback

The award records the reason for the choice, especially when it is not the lowest price. Procura issues unsuccessful bidders a debrief showing their rank, the gap band and the deciding factor, and never the winner's price or name. The buyer gives further helpful feedback to unsuccessful bidders on request, without disclosing another bidder's confidential information.

12.6 No bad-faith RFQs

The buyer issues an RFQ only when it intends to buy, or says clearly in the RFQ that it is a market sounding. It does not use an RFQ to collect free design or advice, to learn competitors' prices, or to pressure a supplier it already has.

12.7 Change, disputes and returns

The buyer changes quantities, specifications, prices or dates through a change order on the platform. It raises disputes and returns through the platform in good faith, keeps to the facts, and takes part fairly in mediation.

12.8 No retaliation

The buyer does not penalise a supplier for asking a clarification question, for declining to bid, for raising a dispute, or for reporting a concern.

12.9 Protect supplier data

The buyer protects supplier data under section 10, and tells Procura promptly if it learns that it has been lost, disclosed or misused.

13. How to report a concern

Anyone may report a concern about conduct on Procura, or a breach of this Code or of its companion Code, to ethics@procuraksa.com. That includes a supplier, a buyer, a user, a sub-supplier, an employee and a member of the public.

13.1 What to report

• suspected bribery, or a gift or hospitality that breaks the rules;
• a conflict of interest that was not disclosed;
• bid rigging, cover bids or price signalling;
• a leaked bid, price or other confidential information;
• a false document, a false claim or a fake account;
• an attempt to take a transaction off the platform to avoid the record;
• forced or child labour, or unsafe conditions, in a supply chain;
• misuse of personal data or of another person's account;
• retaliation for a report, a question or a complaint; and
• anything else that conflicts with this Code.

13.2 What to include

What happened, when, the RFQ, bid, purchase order or invoice number, who was involved, and any document or message that shows it. A report may be made without giving a name. Procura then cannot ask follow-up questions, and a report with little detail may be hard to act on.

For a security vulnerability, write to security@procuraksa.com. For a request about personal data, write to privacy@procuraksa.com.

13.3 Confidentiality

A report is seen only by the people who need it to assess it and act on it. Procura does not tell the person reported who made the report, and protects the reporter's identity as far as the law allows. The law or an authority may in some cases require disclosure.

13.4 No retaliation

Procura does not allow retaliation against anyone who reports a concern in good faith or who helps a review, whether or not the concern proves right. Retaliation includes ending business, dropping a supplier from invitations, lowering a rating, threats, and any other disadvantage. Retaliation is itself a serious breach of this Code, by a buyer or by a supplier. A person who reports in good faith does not lose standing, invitations or ratings on Procura because of it. A report that is knowingly false, or made in bad faith, is also a breach.

13.5 Authorities

Nothing in this Code stops anyone from reporting to a competent authority, such as the Oversight and Anti-Corruption Authority (Nazaha), the General Authority for Competition or the Saudi Data and AI Authority (SDAIA).

13.6 What Procura does with a report

Procura reads each report, decides whether it falls within its role, and applies the same standard whatever the size of the customer concerned. It tells the reporter the outcome where it can do so without harming confidentiality. Procura sets no fixed reply period in this version; the period is an open point for counsel.

Today the channel is a monitored mailbox. A "report a concern" form inside the platform, with a case number, is planned.

14. How Procura responds

14.1 A graduated response

Procura's response is proportionate. It looks at how serious the breach is, whether it was deliberate, whether it was repeated, the harm done, and how the person or organisation cooperates. The steps below are a ladder, not a fixed order: a serious breach can start higher up, and a step can be skipped.

Procura may also ask for corrective action, such as correcting data, withdrawing a false bid or returning an improper benefit, and may record the outcome in the account's history. Suspension may be applied before a full review where that is needed to stop serious harm, for example fraud, bribery, forged documents or a security risk; the notice then follows at once.

14.2 Fair process

Before a decision that restricts an account, Procura tells the person or organisation in writing what is alleged and which section of this Code applies, and gives a reasonable period, stated in the notice and suited to the case, to respond and to provide documents. Procura considers the response and gives its decision in writing with reasons. The decision can be challenged by writing to ethics@procuraksa.com; the challenge is reviewed by a person who took no part in the first decision.

Procura is not a court. It does not decide contract claims between a buyer and a supplier: the purchase order is theirs, and the dispute function of the platform is available to them. A decision under this Code does not limit any right under the law or a contract, or any action by an authority.

14.3 What the platform can do today, and what is planned

15. Acceptance

15.1 Where and when

At the first sign-in after a registration is approved, Procura shows this Code together with the Terms of Use, the Privacy Policy and the other documents that apply to the account, and asks an authorised person to accept them before the account is used for transactions.

15.2 Who accepts

The person who accepts confirms that they are authorised to bind the buying organisation. Users added later are bound through the organisation, and Procura may ask each of them to acknowledge the Code at their own first sign-in.

15.3 The record

Procura records the version, the time, the person and the organisation in its audit trail, and keeps the record with the account's history.

15.4 Questions and disagreement

A person who has a question about this Code, or does not agree with it, should not accept it, and should write to ethics@procuraksa.com. Procura may then be unable to open or keep the account.

16. Version and review

This is version 1.0. The version is shown in the document control table and at the head of the page. Procura reviews the Code at least once a year, and whenever the law or the platform changes in a way that affects it.

A material change gets a new version number and a short summary of what changed, is notified through the platform or by e-mail, and is put to the users for acceptance at their next sign-in. Earlier versions are kept, and are available on request. The version a person accepted is recorded.

The Arabic text is the authoritative text. The English text is provided for convenience. Questions about the Code go to ethics@procuraksa.com.

17. Meaning of some terms