Procurement

Overview

Manages suppliers, purchase requests, approvals, and purchase orders to control spend.

Key concepts

Key terms, statuses, and records that appear in Procurement in XFatora.

Setup & prerequisites

Connect required settings, templates, and defaults for Procurement in XFatora.

Roles & permissions

Assign role-based access, approvals, and visibility for Procurement in XFatora.

Main workflows

Procurement module

manages the purchasing process for your business from internal purchase requests and approvals to creating purchase orders for suppliers, receiving goods, and tracking supplier performance. By using this module, you ensure that all company purchases are documented, authorized, and integrated with inventory and accounting. It introduces control and transparency into acquiring products or services from vendors.

Vendor Management

Suppliers Database:

Begin by populating the modules

Vendors

or

Suppliers

list. For each supplier, record key details: company name, contact persons, addresses, tax/VAT ID, payment terms (e.g. Net 30), and any default currency if they invoice in a foreign currency. There may also be fields for supplier rating or categories (like distinguishing raw material suppliers vs office supply vendors). Having a comprehensive vendor master helps later in selecting the right vendor for a purchase and autofilling POs with correct info.

Supplier Items (Catalog):

If applicable, link suppliers to the items or categories they provide. The module might allow a list of

Vendor Items

for example, Supplier A might be linked to Product X at $5/unit as their price quote. You can maintain a price list for frequently purchased items for each supplier. This isnt mandatory to use the module but is useful for quick PO creation and for comparing quotes.

Vendor Portal:

Procurement often comes with a vendor portal or at least a method to collaborate on POs (the search results showed a vendor_portal directory). If enabled, you can invite vendors to access a portal where they update their company info and possibly view or acknowledge purchase orders. Decide if youll use this it can streamline communications (like a vendor can confirm a PO or upload an invoice). If not using the portal, all interactions will be via email/PDF outside the system, which is fine too.

Purchase Requests and Approvals

Purchase Requisitions:

Team members who need something (e.g., a department needs a new laptop, or production needs raw materials) can initiate a

Purchase Request (PR)

in the system. They fill what they need, quantity, and perhaps a suggested vendor or budget code. These requests are logged and typically require approval. The module will have a

Requests

section where such requisitions reside.

Approval Workflow:

Configure who can approve PRs. The module may allow setting spending limits or an approval matrix (e.g., requests up to $1k can be approved by department manager, beyond that by a director). In settings, define the approvers or use the built-in roles (for example, a role Purchase Manager gets notified of new requests). When a request is submitted, it likely goes into a status

Pending Approval

. Approvers will see it in their queue or get an email. They can then Approve or Reject in the system. Rejections should include a reason (the requester can then edit or cancel the PR). Approved requests move to an

Approved

status and can then be converted into a purchase order.

Budgets (if applicable):

Some procurement systems track budgets. If integrated with the accounting or a budgeting module, a PR might check against remaining budget for that category. If not, its manual: approver should consider if budget allows. The system might allow tagging requests by project or department to later see spend vs budget in reports (some modules have that via linking to accounting when PO is invoiced).

Converting PR to PO:

Once approved, a purchase request can typically be turned into a

Purchase Order

draft with one click. This brings over item details and requested quantity. The procurement officer can then add pricing and vendor info to finalize the PO. This saves re-entering the request details.

Purchase Orders (PO)

Creating a PO:

To create a Purchase Order, go to

Purchase Orders

and click

New PO

. If its from an approved request, link it or convert as said. Otherwise, you can start from scratch. Select the Supplier from the dropdown the vendors details (address, maybe default currency) will fill in. Date and PO Number are generated (the module likely auto-numbers POs uniquely, e.g., PO-2025-001). Then add the order items: select product or service, description, quantity, unit price, and applicable tax (if any). If items are in your

Items list

, you can pick them so you have consistency and integration to inventory if relevant; or you can free-type for one-off items. Ensure the delivery date or expected receipt date is recorded (there may be a field for that especially if you want to track late deliveries).

Terms and Notes:

Theres usually a section for

PO Terms & Conditions

include any standard terms like payment terms, delivery terms (e.g., Delivery Duty Paid, etc.), penalties for late delivery if any, etc. The module might let you define a default terms template that auto-fills for all POs. Also add any remarks or internal notes if needed (internal notes wont print on vendor copy if the system distinguishes them).

Attachments:

If theres any specification document, drawings, or the suppliers quote, attach it to the PO record. You might also attach the approved PR for reference. These attachments can be sent along with the PO to the vendor as needed.

Save and Approve PO:

Depending on your workflow, a PO might need a final approval (maybe by procurement manager if a junior prepared it). The module could have a status like

Draft

then

Approved

. If so, ensure the right person marks it approved. If the PR process was rigorous and PO creation is just clerical, you might skip an extra approval and consider the act of issuing it as approval. Check your company policy. The system might allow multiple states if so, set up notifications so approver knows to approve POs pending.

Issuing the Purchase Order to Vendor

Sending PO:

Once a PO is finalized and approved, its time to send it to the vendor. The module can generate a

PDF

of the PO that looks like a formal order document, listing your company info, vendor info, PO number, date, items, totals, etc. Review this for accuracy. Then use the systems email function: often theres a

Send PO

button which opens an email template with the vendors email filled (from their contact), subject and body. The PO PDF is attached. You can customize the message if needed (e.g., Dear [Vendor], Please find attached our Purchase Order #123. Kindly confirm receipt. Regards...). Click send, and the system will log that an email was sent to vendor (some modules log in an email activity). Alternatively, you could download the PDF and send via your own email, but using the system keeps a record and uses templates.

Vendor Confirmation:

Ideally, vendor replies acknowledging the PO and confirming delivery schedule. If they use the vendor portal, they might be able to click Accept PO or similar. The module has logic to track that e.g., in the PO list, a column for

Confirmed

could update. If using email, you can manually mark the PO as

Confirmed

once the vendor gives the green light. (Some might also partially confirm or propose changes in which case you may edit the PO or create a revised version). Theres likely a field for

Order Status

that can be: Sent, Confirmed, Partially Received, Completed, Cancelled, etc. Mark the statuses accordingly as the process moves forward.

Receipt of Goods/Services

Goods Receipt Note (GRN):

When the supplier delivers the goods, the warehouse or requester should verify the delivery. In the module, go to the PO and record a

Receipt

. This could be done through a function like

Receive Items

or

Create GRN

. Enter the actual received quantities for each line (maybe the supplier short-shipped some items or delivered in batches). If all items are delivered, marking the PO as fully received will close it. If partial, the PO stays open/backorder status and the system might allow multiple GRNs on the same PO until fully delivered. Each GRN typically gets its own reference number (for audit of deliveries).

Quality Check:

If you inspect goods for quality, note any rejections. The module may allow marking some quantity as rejected/returned. For instance, if 100 units delivered but 5 were damaged, you might receive 95 and 5 as

Rejected

(leading to either replacement or credit later). Document that in the receipt notes. Possibly create a Return Order (some systems have a Return to Vendor process integrated the search results show a return_orders view, implying you can initiate a

Return Order

to send back defective goods).

Inventory Integration:

When goods are received and accepted, the module can automatically update the

Inventory module

: increasing stock on hand for those items into the specified warehouse. Ensure each PO item is linked to an inventory item and a warehouse/location for stocking. During receipt, the system will ask which warehouse to put them in (if you have multiple) and then create a stock entry. After posting receipt, check your Inventory the quantities should reflect the new stock. If the inventory module tracks valuation, it may take the PO price to update average cost etc. (some systems do, some need a supplier invoice to finalize cost see next section).

Services or Non-Stock Items:

If the PO was for services or non-tangible items (like consultancy, or an office cleaning contract), theres no physical receipt, but you should still mark the PO as received once the service is rendered satisfactorily. You might simply tick it as received or complete so that it can move to billing stage.

Backorder Tracking:

If a PO is partially delivered, the module should keep it open and show what's still pending. You can send reminders to vendor or track due dates for pending items. Some systems auto-carry undelivered to an updated PO or just leave PO open until complete. Its good practice to regularly review open POs and follow up. The procurement module likely has a report or alert for POs past their delivery date not fully received.

Invoice and Payment

Supplier Invoice Matching:

After or with the delivery, the supplier will send you their

Invoice

(the bill you have to pay). The Procurement module often integrates with accounting or has a sub-module called

Bills

or

Vendor Invoices

. You should record the suppliers invoice in the system and match it to the PO and receipt:

Create a new Bill and reference the PO number. The system may then load the PO lines and quantities (or at least allow linking). Enter the invoice number, date, and the amounts charged. Ideally, the PO price and invoice price should match. If the vendor invoice has any discrepancies (like they charged more for freight, or tax differences), note them. Minor variances can be accepted, or you might dispute if significant. The module might highlight if invoice total > PO total.

If the supplier invoice includes items from multiple POs, you can either split it or link multiple POs to one bill if supported. Or create separate bill entries per PO portion for clarity.

Once you save the bill, it usually goes to

Accounts Payable

in accounting, and possibly triggers the next step in payment workflow.

3-Way Match:

The principle is to match PO, GRN, and Supplier Invoice. The system can help ensure you only pay for what was received and ordered. Check the invoice lines vs what you received. If the vendor invoiced an item not delivered or a higher quantity, you should catch that. The procurement module gives you the data: compare the GRN quantity and the invoice quantity for each line they should align. If not, investigate (maybe a part of delivery is still in transit, or invoice mistake). Only after resolving should you approve the invoice for payment. You might use statuses on the bill like

Unreconciled

vs

Matched

.

Recording Payment:

When you pay the supplier (via bank transfer, etc.), record the payment in the system. If using the integrated accounting, you go to the bill and click

Record Payment

, specifying amount, date, and bank account used. This marks the bill as paid (clearing it from AP aging) and logs the transaction. The procurement module itself might not do the payment part if it hands off to accounting, but since we have integration, it's likely seamless. Paid status might reflect back on the PO or vendor record (like showing total spent vs paid).

Closing the Procurement Loop:

Once a PO is fully received and the vendor paid, mark the PO as

Closed/Completed

if not automatic. The system might auto-close when fully delivered and invoiced. Otherwise, you can manually close it to remove from open list. Maintain records of all documents (PO, GRN, invoice) for audit the system links them, so you can always retrieve and show the chain: PR -> PO -> GRN -> Bill -> Payment. This traceability is gold for both auditing and evaluating supplier performance (like how often did they deliver late or overcharge).

Additional Features and Best Practices

Requisition-to-Order Cycle in UI:

Many modules have a dashboard or Kanban: Request (x pending approval), PO (y sent, z awaiting delivery), etc. Use that to manage workload. Perhaps procurement staff check daily for any new approved requests to convert to PO, and check for POs overdue for delivery.

Quotation Management:

Sometimes before creating a PO, you might request quotes from multiple vendors. The module might have a

Request for Quotation (RFQ)

feature: you create an RFQ listing needed items and can record responses from multiple vendors, then pick one to convert to PO. If the module supports it, use it when competitive bidding is required. It can even generate comparative statements. If not built-in, you might handle externally and just choose vendor in PO after.

Vendor Performance Tracking:

Over time, you can analyze data in the module e.g., average delivery delay per vendor, number of rejected items, price trends. The procurement module likely has

Reports

like Purchase Volume by Vendor, On-time Delivery %, etc. Use these for periodic vendor reviews and negotiation. For instance, if a vendor frequently delivers short, you have data to discuss improvement or maybe switch vendor.

Budget Control:

If you have budgets for departments or projects, coordinate with finance. While procurement ensures processes are followed, watch the spend by category. The procurement module might show total purchases per department vs budget (if budget figures are input somewhere). If not automatic, run reports monthly and share with department heads to avoid overspending surprises.

Policy Compliance:

Use the system to enforce procurement policies. For example, you might have a rule that any purchase above $5k requires 3 quotes and CFO approval. The modules process can accommodate: a PR for >$5k should perhaps attach 3 quotes and then CFO is set as approver in that case. Or use an approval matrix. The goal is to ensure no one skirts procedure because the system records each step, it deters maverick spending.

Integration with Accounting & Inventory Recap:

Inventory:

POs feed into Inventory on receipt, meaning stock levels update without separate entries. Confirm that each inventory item has proper units and cost capturing (some systems allow capturing actual purchase cost which can update item standard cost or be used for valuation likely you might stick to weighted average). The module has a

Warehouse

selection on PO and GRN; always set to the correct one to keep stock accurate per location.

Accounting:

When you mark a bill for a PO as paid or approved, the accounting sees the expense. Ensure tax from supplier bills is captured (the bill entry will have tax lines if vendor charges VAT that will go to your VAT payable for input credit). The system possibly can auto-fill tax from PO or item settings. Check AP Aging to manage cash flow procurement can feed that by telling finance which big supplier payments are upcoming (the AP reports can show due dates based on payment terms recorded for each bill).

Security & Access:

Limit who can create and approve PRs/POs with user roles. For instance, normal staff can make PRs but not see supplier pricing or other depts POs; procurement officers can create POs but not approve their own maybe; managers can approve; finance can see all for reconciliation. Use the modules permission settings to set that up. This prevents unauthorized ordering or data snooping (like a salesperson shouldnt necessarily see the cost you buy goods from suppliers, if thats sensitive).

Continuous Improvement:

Evaluate the data from procurement to refine your processes. Are there recurrent delays in approvals slowing things? Maybe adjust threshold or add backup approvers. Are there too many urgent PRs indicating poor planning? Work with teams to forecast needs better so procurement can bundle orders (often ordering in bulk yields discounts). Use the modules info to foresee and negotiate e.g., if you realize you raise 10 POs for office supplies each quarter, maybe better to negotiate a standing order or contract with that vendor.

By diligently using the Procurement module, you achieve

a structured, transparent purchasing process

that aligns with internal controls and optimizes supplier relations. Over time, this reduces costs (through better negotiation and avoiding rush orders), prevents fraud/waste (since everything is approved and matched), and ensures operational needs are met on schedule. It transforms procurement from an ad-hoc task into a strategic function supported by real data and workflows.

Screens & fields reference

Use these screens and fields to complete tasks inside Procurement in XFatora.

Automations & notifications

Review automation rules and notifications available in Procurement in XFatora.

Reports & dashboards

Track KPIs and dashboards powered by Procurement in XFatora.

Common mistakes

• Skipping required configuration before the first workflow.
• Not assigning the correct permissions for team roles.
• Forgetting to review automation or notification settings.

FAQs

Troubleshooting

Related modules