{"id":650,"date":"2026-08-20T18:54:33","date_gmt":"2026-08-20T18:54:33","guid":{"rendered":"https:\/\/zamacore.com\/blog\/?p=650"},"modified":"2026-08-20T19:01:44","modified_gmt":"2026-08-20T19:01:44","slug":"goods-received-note-software-kenya","status":"publish","type":"post","link":"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/","title":{"rendered":"Goods Received Note Software Kenya: Control Partial Deliveries, Rejections and Stock Posting"},"content":{"rendered":"<p><!-- zama-client-demand-20:2026-08-20 site=zamacore slug=goods-received-note-software-kenya --><\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_85 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Turn_every_delivery_into_controlled_receiving_evidence\" >Turn every delivery into controlled receiving evidence<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#What_the_workflow_should_achieve\" >What the workflow should achieve<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#A_realistic_Kenyan_operating_scenario\" >A realistic Kenyan operating scenario<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#The_records_and_definitions_to_agree_first\" >The records and definitions to agree first<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#A_practical_end-to-end_process\" >A practical end-to-end process<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Exceptions_the_demonstration_must_include\" >Exceptions the demonstration must include<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Roles_permissions_and_segregation_of_duties\" >Roles, permissions and segregation of duties<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Capabilities_worth_putting_in_the_scope\" >Capabilities worth putting in the scope<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Integrations_identifiers_and_failure_handling\" >Integrations, identifiers and failure handling<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Operational_views_and_management_reporting\" >Operational views and management reporting<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Security_privacy_and_audit_evidence\" >Security, privacy and audit evidence<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#How_to_run_a_controlled_pilot\" >How to run a controlled pilot<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Measures_that_can_show_whether_the_process_is_improving\" >Measures that can show whether the process is improving<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Common_implementation_mistakes\" >Common implementation mistakes<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Questions_to_use_in_a_serious_software_demo\" >Questions to use in a serious software demo<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Related_ZamaCore_resources\" >Related ZamaCore resources<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Frequently_asked_questions\" >Frequently asked questions<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-18\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#What_is_a_goods_received_note\" >What is a goods received note?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-19\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Can_GRN_software_handle_partial_deliveries\" >Can GRN software handle partial deliveries?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-20\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Should_rejected_goods_increase_available_stock\" >Should rejected goods increase available stock?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-21\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Does_a_GRN_approve_a_supplier_invoice_for_payment\" >Does a GRN approve a supplier invoice for payment?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-22\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#What_should_we_bring_to_a_GRN_software_demo\" >What should we bring to a GRN software demo?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-23\" href=\"https:\/\/zamacore.com\/blog\/goods-received-note-software-kenya\/#Discuss_this_workflow_with_ZamaCore\" >Discuss this workflow with ZamaCore<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Turn_every_delivery_into_controlled_receiving_evidence\"><\/span>Turn every delivery into controlled receiving evidence<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/08\/goods-received-note-software-kenya-featured-2026-08-20.jpg\" alt=\"Goods received note software Kenya workflow at a warehouse receiving bay\"><figcaption>A receiving team checks delivered, damaged and accepted quantities before stock is posted.<\/figcaption><\/figure>\n<p><strong>goods received note software Kenya<\/strong> is useful when a business needs to control a specific operational decision, not when it merely wants another screen. A supplier vehicle arrives, but the purchase order, physical delivery and invoice do not agree. Staff sign a delivery note, write a quantity in a book and promise to update stock later. Short, damaged or substituted items then become difficult to trace.<\/p>\n<p>Weak receiving evidence can overstate stock, delay supplier queries, create invoice disputes and hide which person accepted a variance. The operational problem is not the absence of a GRN number; it is the absence of one dependable record connecting the order, inspection, acceptance and stock movement. This guide is written for warehouse managers, stores teams, procurement officers, finance controllers and operations leaders that receive supplier goods. It explains what to record, which exceptions must stay visible, how to structure a pilot and what a serious buyer should ask to see in a demonstration.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"What_the_workflow_should_achieve\"><\/span>What the workflow should achieve<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The workflow should show what was ordered, what physically arrived, what was accepted into usable stock, what was held or rejected, and what remains outstanding. It should allow a receiver to capture a partial delivery without closing the order and give procurement and finance enough evidence to follow the balance.<\/p>\n<p>This use case begins when goods reach the receiving point and ends when accepted quantities are posted, rejected quantities are dispositioned and the related order balance is clear. It does not replace sourcing, quotation evaluation or the whole accounts-payable process. That boundary matters because a narrow, complete workflow is easier to test than a broad promise. It also prevents this use case from competing with a general ERP, inventory, procurement or analytics page that owns a wider buying intent.<\/p>\n<p>A useful design begins with the source transaction and ends with an authorised, traceable outcome. It should preserve the normal path and the difficult path: missing information, partial work, a rejected item, a late response, a correction and an approved override. If staff must leave the system and solve every exception through calls or private messages, management still lacks dependable operational evidence.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"A_realistic_Kenyan_operating_scenario\"><\/span>A realistic Kenyan operating scenario<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A Nairobi distributor orders 100 neutral cartons from a supplier. The truck brings 86. Four cartons are visibly damaged and two carry an item variant that was not ordered. The storekeeper must record the delivery against the authorised purchase order, accept only the valid quantity, isolate exceptions and preserve the supplier driver\u2019s delivery reference.<\/p>\n<p>The demonstration should show whether the accepted quantity becomes available stock only after the required check, whether the damaged and substituted goods remain outside usable inventory, whether the open purchase-order balance remains visible, and whether finance can distinguish an unresolved delivery from a fully received order.<\/p>\n<p>During discovery, bring actual forms, spreadsheets, transaction samples and reports with sensitive details removed. Name the people who create, check, approve, correct and use the record. This gives the implementation team enough context to distinguish required controls from habits that can be simplified.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"The_records_and_definitions_to_agree_first\"><\/span>The records and definitions to agree first<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Reliable receiving depends on clean supplier, item, unit-of-measure, warehouse and purchase-order records. The team should also agree which delivery references must be unique and whether inspection status is recorded by line, batch, package or whole delivery.<\/p>\n<ul>\n<li>Ordered quantity: the authorised quantity on the current purchase-order line, including approved changes.<\/li>\n<li>Delivered quantity: everything physically presented at receiving before quality or condition decisions.<\/li>\n<li>Accepted quantity: goods approved for the intended stock status and location.<\/li>\n<li>Held quantity: goods kept separate while information, inspection or approval is pending.<\/li>\n<li>Rejected or returned quantity: goods not accepted, with a controlled reason and next action.<\/li>\n<li>Outstanding quantity: the approved order balance still expected after the receipt is processed.<\/li>\n<\/ul>\n<p>Agree these definitions in plain language and nominate a data owner for each one. The same term can mean different things to stores, finance, production, quality and sales. A system cannot produce trusted reports when departments use different units, dates, statuses or reasons for the same event. Controlled lists should therefore be reviewed deliberately rather than expanded whenever a user wants a new label.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"A_practical_end-to-end_process\"><\/span>A practical end-to-end process<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ol>\n<li><strong>Identify the authorised order.<\/strong> Search or select the approved purchase order and confirm supplier, delivery site, item, unit, expected quantity and order status before recording a receipt.<\/li>\n<li><strong>Register the delivery event.<\/strong> Capture delivery date and time, supplier delivery reference, vehicle or courier reference where needed, receiver and supporting document without treating the supplier note as proof of acceptance.<\/li>\n<li><strong>Count and inspect by line.<\/strong> Record presented quantity, condition and any item mismatch. Keep delivered, accepted, held, rejected and returned quantities distinct instead of overwriting one number.<\/li>\n<li><strong>Resolve controlled exceptions.<\/strong> Assign short deliveries, excess quantities, damage, substitution and missing documentation to the correct procurement, quality or stores owner.<\/li>\n<li><strong>Post authorised stock.<\/strong> Create inventory movements only for quantities and statuses that the organisation permits. Preserve the relationship between the movement and the receipt line.<\/li>\n<li><strong>Close or keep the balance open.<\/strong> Complete the receipt, leave valid order quantities outstanding for a later delivery and give finance a clear matching status.<\/li>\n<\/ol>\n<p>Each stage should have an entry condition, responsible role, permitted action and visible completion rule. Notifications can help, but a message is not the workflow. The authoritative record must remain searchable inside the system, including what changed, who decided, why an exception was accepted and which downstream record was updated.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Exceptions_the_demonstration_must_include\"><\/span>Exceptions the demonstration must include<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The happy path is usually the easiest part of a software demonstration. Operational value appears when the team can see, own and resolve deviations without corrupting the original record. Ask the vendor to demonstrate these representative cases:<\/p>\n<ol>\n<li><strong>A partial delivery.<\/strong> Receive the accepted portion while retaining the outstanding balance, promised follow-up date and owner. Do not force staff to mark the order complete merely to post stock.<\/li>\n<li><strong>Damaged goods.<\/strong> Record the damaged quantity and condition evidence, place it in the correct non-usable status and route the supplier decision without adding it to available stock.<\/li>\n<li><strong>An unordered substitution.<\/strong> Keep the offered item separate and require an authorised acceptance or return decision. A receiver should not silently change the purchase-order item.<\/li>\n<li><strong>Excess quantity.<\/strong> Show the ordered and offered quantities, prevent accidental over-receipt where policy requires, and route any approved tolerance or order change.<\/li>\n<li><strong>Duplicate delivery paperwork.<\/strong> Detect a repeated supplier reference or suspicious duplicate receipt and require review before another stock movement is created.<\/li>\n<\/ol>\n<p>An exception should not be deleted merely because it is uncomfortable. It needs a reason, evidence where appropriate, an owner, a next action and a final disposition. Over time, exception patterns help process owners improve supplier instructions, training, maintenance, product design or approval rules without relying on anecdotes.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Roles_permissions_and_segregation_of_duties\"><\/span>Roles, permissions and segregation of duties<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Receiving staff need speed at the bay, but they should not inherit procurement or finance authority by accident. The design can separate physical receipt, quality disposition, order-change approval and stock adjustment while still keeping the process usable.<\/p>\n<ul>\n<li>Receiver: registers the delivery, counts items and records visible condition.<\/li>\n<li>Stores supervisor: reviews exceptions and confirms permitted stock status or location.<\/li>\n<li>Procurement officer: follows shortages, substitutions, excess quantities and supplier commitments.<\/li>\n<li>Quality reviewer: controls hold, acceptance or rejection where inspection is required.<\/li>\n<li>Finance user: sees matching evidence but does not alter the physical receipt.<\/li>\n<li>System administrator: maintains configuration without approving operational transactions.<\/li>\n<\/ul>\n<p>A permission model should be demonstrated with real role scenarios. Ask who can create, edit, approve, reopen, cancel, export and configure a record. Shared accounts weaken accountability. Broad administrator access should be limited, reviewed and logged. Temporary delegation should record the delegating person, substitute, effective period and actions taken during that period.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Capabilities_worth_putting_in_the_scope\"><\/span>Capabilities worth putting in the scope<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>A request for proposal becomes more useful when it describes testable behaviour rather than asking whether a product has a module with a familiar name. For this workflow, consider the following capabilities and confirm which are standard, configurable or require development:<\/p>\n<ul>\n<li>Purchase-order line lookup and remaining-balance visibility<\/li>\n<li>Partial receipt without premature order closure<\/li>\n<li>Separate delivered, accepted, held, rejected and returned quantities<\/li>\n<li>Condition and discrepancy reason capture<\/li>\n<li>Attachment of delivery documents and controlled evidence<\/li>\n<li>Receiving, inspection and stock-posting statuses<\/li>\n<li>Duplicate-reference and over-receipt warnings<\/li>\n<li>Approval paths for tolerances, substitutions and order changes<\/li>\n<li>Linked inventory movement and receipt history<\/li>\n<li>Outstanding-delivery and unresolved-exception reporting<\/li>\n<\/ul>\n<p>Not every organisation needs every capability in the first release. Classify requirements as essential for the pilot, needed for rollout, or a future improvement. This keeps the first implementation coherent while preserving a documented path for later phases.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Integrations_identifiers_and_failure_handling\"><\/span>Integrations, identifiers and failure handling<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The receipt normally connects procurement, supplier master data, inventory, quality controls and accounts payable. If these are separate systems, agree whether the purchase order is copied or queried, which system creates the stock movement and how finance learns that a receipt has been corrected, cancelled or reopened.<\/p>\n<p>For every connection, name the source of truth, matching identifier, direction of data, update frequency, permitted fields and reconciliation owner. Ask what users see when an interface is unavailable, a record is rejected, a duplicate is detected or a message arrives out of sequence. A successful technical response is not the same as a completed business transaction.<\/p>\n<p>Data migration deserves the same care. Clean a representative sample before estimating the full effort. Preserve original references where they are needed for audit or lookup, document transformations, and reconcile control totals after loading. Historical data can be archived or migrated at different levels, but the decision should be explicit and tested.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Operational_views_and_management_reporting\"><\/span>Operational views and management reporting<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Stores needs today\u2019s deliveries, receipts waiting for inspection and quantities held outside available stock. Procurement needs short, late and disputed order balances by supplier. Finance needs orders with complete, partial, rejected or missing receipt evidence. Management may need receiving turnaround, recurring discrepancy reasons and unclosed receipt exceptions.<\/p>\n<p>Every headline measure needs an agreed formula, reporting period, data owner and drill-down path. Terms such as open, late, rejected, completed, available, loss and value are not self-explanatory. An authorised manager should be able to move from a summary to the transactions behind it and see when the data was last updated.<\/p>\n<p>A dashboard should prompt action rather than decorate a meeting. Define which threshold creates an alert, who receives it, what response is expected and when an unresolved issue escalates. Keep the first dashboard small enough that each measure has an owner and a practical response.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Security_privacy_and_audit_evidence\"><\/span>Security, privacy and audit evidence<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The workflow should collect only information required for its operational purpose and restrict it according to responsibility. Buyers should review authentication, session management, sensitive exports, approval authority, configuration changes, backup restoration, retention and incident response in proportion to the risk. If external users participate, their access must remain limited to the records and actions intended for their organisation.<\/p>\n<p>An audit history is useful when it can answer: who created the record, what changed, which value was replaced, who approved the decision, when it became effective and what happened downstream. Corrections should preserve the original event and the authorised reason instead of silently rewriting history. Export and deletion rules should be agreed before launch, not invented during an investigation.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"How_to_run_a_controlled_pilot\"><\/span>How to run a controlled pilot<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Pilot one warehouse and a small group of suppliers whose deliveries include both normal and difficult cases. Include a full delivery, a partial delivery, damage, an excess quantity, a substituted item, a correction and a later balance delivery. Do not test only clean orders.<\/p>\n<ol>\n<li><strong>Map the receiving point.<\/strong> Observe the physical steps, documents, devices, inspection space and shift handovers before designing screens.<\/li>\n<li><strong>Clean representative masters.<\/strong> Confirm item codes, purchase-order units, warehouse locations and supplier references for a sample set.<\/li>\n<li><strong>Configure status and authority.<\/strong> Agree who may receive, hold, reject, approve tolerances, correct and post stock.<\/li>\n<li><strong>Test downstream movements.<\/strong> Reconcile receipt lines to inventory and finance records for normal and exception cases.<\/li>\n<li><strong>Train with real scenarios.<\/strong> Use de-identified delivery documents and require staff to resolve rather than skip exceptions.<\/li>\n<li><strong>Review the pilot evidence.<\/strong> Compare receipt completeness, outstanding balances, correction volume and user questions before rollout.<\/li>\n<\/ol>\n<p>At the pilot review, separate configuration defects, data problems, training gaps, process-policy questions and genuinely new scope. Record decisions and re-test the affected scenario. Expansion should depend on acceptance evidence and user readiness, not on a demonstration that covered only the normal path.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Measures_that_can_show_whether_the_process_is_improving\"><\/span>Measures that can show whether the process is improving<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Record a baseline before changing the process. Useful measures for this use case can include:<\/p>\n<ul>\n<li>Deliveries recorded on the day they arrive<\/li>\n<li>Receipt lines waiting for inspection or approval<\/li>\n<li>Short, damaged, excess and substituted quantities by reason<\/li>\n<li>Purchase orders left open after partial receipt<\/li>\n<li>Stock movements reversed because of receiving errors<\/li>\n<li>Supplier invoices blocked by missing or unresolved receipt evidence<\/li>\n<li>Average age of open receiving exceptions<\/li>\n<li>Duplicate supplier delivery references detected for review<\/li>\n<\/ul>\n<p>These are measurement candidates, not promised results. Select only the measures the organisation can define and collect consistently. Document changes in volume, seasonality, product mix or policy that could affect the comparison. Credible operational learning is more valuable than an unsupported return-on-investment claim.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Common_implementation_mistakes\"><\/span>Common implementation mistakes<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ul>\n<li>Treating the supplier delivery note as proof that all goods were accepted<\/li>\n<li>Posting delivered quantity to available stock before condition decisions<\/li>\n<li>Forcing partial deliveries into a closed-order status<\/li>\n<li>Allowing receivers to alter ordered items or quantities without approval<\/li>\n<li>Creating free-text discrepancy reasons that cannot be analysed<\/li>\n<li>Ignoring reversals, corrections and shift handovers in acceptance testing<\/li>\n<li>Designing software without considering the physical hold and return process<\/li>\n<\/ul>\n<p>Put the relevant risks into the project register with an owner and decision date. A polished interface cannot compensate for missing process owners, unreliable master data, unavailable frontline users or acceptance tests that were never agreed.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Questions_to_use_in_a_serious_software_demo\"><\/span>Questions to use in a serious software demo<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ul>\n<li>Can you receive part of one purchase-order line and keep the balance open?<\/li>\n<li>How are delivered, accepted, held, rejected and returned quantities distinguished?<\/li>\n<li>What prevents the same delivery reference from creating duplicate stock?<\/li>\n<li>Who can approve an over-receipt or an unordered substitution?<\/li>\n<li>Can a stock movement be traced back to its exact GRN line and decision?<\/li>\n<li>What happens when a receipt is corrected after finance has begun matching?<\/li>\n<li>Which unresolved exceptions appear in stores, procurement and finance queues?<\/li>\n<li>Can the system demonstrate a return and a later replacement delivery?<\/li>\n<\/ul>\n<p>Use representative but de-identified records for the demo. Ask the presenter to complete the transaction rather than describe what could be configured later. Note which behaviour is available now, which requires configuration, which requires integration and which is outside scope. Confirm discovery, implementation, hosting, support, security updates, data export, source-code terms where relevant and exit arrangements in writing.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Related_ZamaCore_resources\"><\/span>Related ZamaCore resources<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ul>\n<li><a href=\"https:\/\/zamacore.com\/solutions\/inventory-management-software-kenya\">inventory management software in Kenya<\/a><\/li>\n<li><a href=\"https:\/\/zamacore.com\/solutions\/erp-software-development-kenya\">ERP software development in Kenya<\/a><\/li>\n<li><a href=\"https:\/\/zamacore.com\/blog\/procurement-approval-workflow-system-kenya\/\">procurement approval workflow software<\/a><\/li>\n<li><a href=\"https:\/\/zamacore.com\/contact\">contact ZamaCore<\/a><\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Frequently_asked_questions\"><\/span>Frequently asked questions<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"What_is_a_goods_received_note\"><\/span>What is a goods received note?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>A goods received note is the organisation\u2019s record of what physically arrived and how it was handled. A useful GRN distinguishes delivery from acceptance, links the event to an authorised order and preserves shortages, damage, holds, rejections and returns. It should not be confused with the supplier\u2019s delivery note.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Can_GRN_software_handle_partial_deliveries\"><\/span>Can GRN software handle partial deliveries?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>It can be designed to record the accepted portion while keeping the authorised balance open. The workflow should show what remains due, which exceptions need follow-up and whether a later delivery closes the line. Buyers should test this with a real multi-line order.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Should_rejected_goods_increase_available_stock\"><\/span>Should rejected goods increase available stock?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Not automatically. Rejected or held goods should remain in a status and physical area that prevents unintended use. The exact treatment depends on the organisation\u2019s inventory and quality policy, but the system should make the distinction visible and traceable.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Does_a_GRN_approve_a_supplier_invoice_for_payment\"><\/span>Does a GRN approve a supplier invoice for payment?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>A GRN provides receiving evidence, but payment approval may require the authorised purchase order, supplier invoice, tax and finance checks, and resolution of price or quantity differences. The workflow should support that evidence chain without giving receiving staff payment authority.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"What_should_we_bring_to_a_GRN_software_demo\"><\/span>What should we bring to a GRN software demo?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Bring a normal purchase order and examples involving shortage, damage, excess quantity, substitution, a later balance delivery and a corrected receipt. Remove confidential data, but preserve the decisions and document relationships the team needs to test.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Discuss_this_workflow_with_ZamaCore\"><\/span>Discuss this workflow with ZamaCore<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Use one recent difficult delivery to map the purchase order, physical count, acceptance decision, stock movement and finance hand-off. ZamaCore can review the workflow through an online demo or an appointment-based in-person discussion at the Zama Systems office in Karuguru Plaza along Eastern Bypass. Bring a representative form, spreadsheet, report or de-identified transaction so the discussion stays grounded in the way your team actually works.<\/p>\n<p><a href=\"https:\/\/zamacore.com\/contact\"><strong>Request a ZamaCore workflow discovery or demo appointment<\/strong><\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Use goods received note software Kenya teams can configure to record partial deliveries, rejected items, approvals and accurate stock posting.<\/p>\n","protected":false},"author":1,"featured_media":649,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-650","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/650","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/comments?post=650"}],"version-history":[{"count":1,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/650\/revisions"}],"predecessor-version":[{"id":651,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/650\/revisions\/651"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media\/649"}],"wp:attachment":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media?parent=650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/categories?post=650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/tags?post=650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}