Goods Received / Item Receipt
Overview
The Goods Received API allows your ERP or warehouse management system to send item receipt confirmations to SoftCo, enabling three-way matching between purchase orders, goods receipts, and supplier invoices. For organisations where receipting_required is set to true on a purchase order line, SoftCo will hold the corresponding invoice for approval until a matching goods receipt has been received through this API — ensuring that payment is only authorised for goods and services that have actually been delivered.
A single call to POST /goods-received/v1 submits one or more goods receipt records. Each record carries a GRN header with receipt details and supplier information, and a rows array of line items. Crucially, the po_number reference is carried at line level — not on the header — which means a single GRN can acknowledge receipt of items from multiple purchase orders in one submission. SoftCo matches each line against the relevant PO using the combination of po_number and line_number.
Where Goods Received fits in the AP workflow
Once a purchase order is in SoftCo and a supplier sends an invoice, the three-way matching process checks whether the invoiced items have actually arrived. When your team books a goods receipt or confirms service delivery in your ERP, that confirmation needs to reach SoftCo via this API. Without it, invoices on PO lines with receipting required will remain on hold, pending confirmation. Sending timely GRN data therefore directly affects how quickly invoices can be approved and paid.
Unlike purchase orders, where the PO number sits on the header, goods receipts carry po_number on each individual line item. This reflects how receipts work in practice — a single delivery note or goods receipt document can contain items from several different purchase orders. Each line identifies the specific PO it is fulfilling.
When to call this endpoint
receipting_required is true, send an item receipt once the service has been signed off, with the delivered quantity as quantity_received.
Resubmitting a GRN record is safe — SoftCo will refresh the receipt data for the matching grn_number. This makes it straightforward to correct a receipt or replay a missed submission.
Quick Start
Here is the minimum viable GRN — a single receipt with two line items acknowledging delivery against a purchase order. The required header fields are grn_number, grn_date, and grn_supplier_number. Each line in the rows array requires row_id, line_number, po_number, quantity_received, and uom.
POST /goods-received/v1 x-api-key: your-api-key-here Content-Type: application/Json Client_Id: your-client-id Client_Secret: your-client-secret { "objects": { "object": { "record": [ { "organization": "main", "grn_number": "GRN-2024-04521", "grn_date": "2024-03-18", "grn_supplier_number": "SUP-001234", "grn_supplier_name": "Acme Office Supplies Ltd", "received_by": "Ciara Brennan", "rows": [ { "row_id": "1", "line_number": 1, "po_number": "PO-2024-00891", "item_number": 1, "item_description": "A4 Copy Paper — 5 Ream Box", "quantity_received": 10, "uom": "BOX" }, { "row_id": "2", "line_number": 2, "po_number": "PO-2024-00891", "item_number": 4, "item_description": "Printer Ink Cartridge — Black", "quantity_received": 5, "uom": "EA" } ] } ] } } }
A successful response looks like this:
{ "status": "SUCCESS", "total": 1, "succeeded": 1, "failed": 0, "errors": [], "message": "All records processed successfully." }
A 202 Accepted means your goods receipt has been validated and queued. Once delivered to SoftCo, it is matched against the referenced purchase order lines. Any invoice held pending a receipt confirmation for those lines will be released for approval processing. If the release does not occur within a few minutes, see the Troubleshooting section.
How It Works
Every request follows the same pipeline. Your system sends once — validation, transformation, and delivery to SoftCo are handled automatically.
Layer
Queue
AP
POST /goods-received/v1 with your credentials and one or more GRN records — each containing receipt header details and a rows array of line items, each with its own po_number reference.401 Unauthorized before your payload is processed.rows array with its required line-level fields. If anything fails, you get a 400 Bad Request with a field-level error message. Nothing is queued until validation passes.202 Accepted immediately — no further action is needed from your side.po_number and line_number. Any invoice that was held pending a goods receipt confirmation for those lines is released for approval processing. If SoftCo is temporarily unavailable, the queue holds the record and retries delivery automatically.202 Accepted does not mean the invoice has been released yet — it means your GRN has been received, validated, and queued successfully. Matching and invoice release in SoftCo AP is asynchronous and typically completes within minutes. If an invoice remains on hold after a reasonable period, confirm the po_number and line_number values match the PO exactly, then contact your SoftCo Customer Success representative.
Rate limits are configured per customer during onboarding. If you receive a 429 Too Many Requests response, reduce your request rate and retry after a short delay. For your specific rate limit thresholds, contact your SoftCo Customer Success representative.
Authentication
All requests require an API key and OAuth 2.0 credentials. Your credentials are provided during onboarding — keep them secure and never expose them in client-side code or version control.
Requests with a missing or invalid API key are rejected by the gateway immediately and never reach the integration layer.
Required Headers
| Header | Value | Notes |
|---|---|---|
| x-api-key | Your assigned API key | Provided at onboarding. Required on every request. |
| Client_Id | OAuth 2.0 Client ID | Provided at onboarding. |
| Client_Secret | OAuth 2.0 Client Secret | Treat as a password — do not share or log. |
| Access_Token_URL | OAuth 2.0 token endpoint | Provided at onboarding. |
| Content-Type | application/Json | Must be present on every POST request. |
Contact your SoftCo Customer Success representative immediately to rotate your API key. Do not attempt to use the same credentials across multiple customer environments.
Response Codes
| Code | Status | Meaning | What to do |
|---|---|---|---|
| 202 | Accepted | Payload validated and queued. Delivery to SoftCo is in progress. | Nothing — your goods receipt is on its way. |
| 207 | Multi-Status | Batch partially accepted. Valid records were queued; one or more failed validation. Check the errors array for details on failing records. | Inspect the errors array by record index, correct the failing records, and resubmit only those that failed. |
| 400 | Bad Request | Payload failed schema validation. A field-level error is in the response body. | Read the message and errors fields, fix the payload, retry. See Troubleshooting. |
| 401 | Unauthorized | API key missing or invalid. | Check your x-api-key header value. |
| 403 | Forbidden | Valid API key but no permission for this endpoint. | Contact your SoftCo Customer Success representative. |
| 404 | Not Found | Endpoint path is incorrect. | Verify the URL — check for typos or trailing slashes. |
| 408 | Request Timeout | Request took too long to process. | Retry once after a short delay. |
| 429 | Too Many Requests | Rate limit exceeded. | Slow your request rate and retry after the delay indicated. |
| 500 | Internal Server Error | Unexpected error on our side. | Retry once. If it persists, raise a ticket with the requestId. |
| 503 | Service Unavailable | Service temporarily unavailable. | Retry after a short delay. |
POST /goods-received/v1
Submit one or more goods receipt records to SoftCo. Each record carries GRN header information and a rows array of line items. Each line identifies the purchase order it is fulfilling via po_number and the quantity delivered via quantity_received. SoftCo matches these against the corresponding PO lines and releases any held invoices once the receipt is confirmed.
Request Headers
| Header | Value |
|---|---|
| x-api-key | Your assigned API key. |
| Content-Type | application/Json |
| Client_Id | Your OAuth 2.0 Client ID. |
| Client_Secret | Your OAuth 2.0 Client Secret. |
| Access_Token_URL | Your OAuth 2.0 token endpoint URL. |
Request Body
The Goods Received API uses the standard SoftCo iPaaS envelope: objects → object → record. For all GRN requests, record is a JSON array with line items nested inside a rows as a JSON array.
Single goods receipt
Batch (multiple goods receipts)
Field Reference
The Goods Received API carries 62 fields across two levels: GRN header fields that apply to the entire receipt document, and line item fields within the rows array. The header includes groups for receipt identity, shipping documents, supplier details, receiving site, and optional custom extensibility fields.
GRN Header Fields
These fields sit directly within the record object and describe the goods receipt document as a whole.
| Field | Type | Required | Description |
|---|---|---|---|
| organization | string | Recommended | The SoftCo organisation entity this GRN belongs to. Defaults to "main" if omitted.
Default:
"main" |
| system | string | Recommended | Identifier for the source system submitting the GRN — for example your ERP or warehouse management system name. Used for traceability. |
| record_id | string | Required | Your system's internal reference for this record submission. Useful for correlating API submissions back to records in your ERP. |
| grn_number | string | Required | The goods receipt note number from your ERP or warehouse system. This is the primary identifier SoftCo uses to reference and refresh the receipt record.
e.g. "GRN-2024-04521"
|
| grn_date | string | Required | The date the goods were received or the service was confirmed. Format: YYYY-MM-DD.
e.g. "2024-03-18"
|
| received_by | string | Optional | The name or identifier of the person who accepted the delivery or confirmed the service.
e.g. "Ciara Brennan"
|
| grn_comment | string | Optional | Free-text notes about the receipt — for example notes on damaged goods, partial delivery, or receipt conditions. |
Shipping Document Fields
These fields capture the reference numbers and dates from the shipping and delivery documentation accompanying the goods. They provide an audit trail linking the goods receipt back to the supplier's dispatch documents.
| Field | Type | Required | Description |
|---|---|---|---|
| bol_number | string | Optional | Bill of Lading number — the carrier's reference for the shipment. Relevant for freight shipments where a bill of lading is issued by the carrier.
e.g. "BOL-2024-88712"
|
| bol_date | string | Optional | The date on the Bill of Lading. Format: YYYY-MM-DD. |
| delivery_slip | string | Optional | The delivery slip or delivery note number provided by the supplier with the shipment.
e.g. "DS-ACM-20240318"
|
| delivery_slip_date | string | Optional | The date on the supplier's delivery slip. Format: YYYY-MM-DD. |
| packing_slip_number | string | Optional | The packing slip number included with the shipment, listing the items packed. |
| packing_slip_date | string | Optional | The date on the packing slip. Format: YYYY-MM-DD. |
Supplier Fields
Supplier fields identify the vendor from whom the goods were received. grn_supplier_number is the required reference; the remaining fields carry address and identification detail for the supplier as recorded in your ERP at the time of receipt.
| Field | Type | Required | Description |
|---|---|---|---|
| grn_supplier_number | string | Required | The vendor ID from your ERP — the primary identifier linking this receipt to a supplier. Should match the supplier_number on the originating purchase order.
e.g. "SUP-001234"
|
| grn_supplier_site_code | string | Optional | The site or location code for this supplier, where a supplier has multiple sites.
e.g. "DUBLIN-01"
|
| grn_supplier_name | string | Optional | The supplier's trading name as recorded in your ERP at the time of receipt.
e.g. "Acme Office Supplies Ltd"
|
| grn_supplier_address1 | string | Optional | First line of the supplier's address. |
| grn_supplier_address2 | string | Optional | Second line of the supplier's address. |
| grn_supplier_city | string | Optional | City of the supplier's address. |
| grn_supplier_postcode | string | Optional | Postcode or ZIP of the supplier's address. |
| grn_supplier_state | string | Optional | State, province, or county of the supplier's address. |
| grn_supplier_country | string | Optional | Country of the supplier's address. |
Receiving Site Fields
These fields identify the physical location where the goods were received. For organisations with multiple sites or warehouses, sending site details allows SoftCo to associate the receipt with the correct receiving location.
| Field | Type | Required | Description |
|---|---|---|---|
| site_name | string | Optional | The name of the receiving site or warehouse.
e.g. "Dublin Distribution Centre"
|
| site_number | string | Optional | Your ERP's internal site or location number for the receiving site.
e.g. "SITE-003"
|
| site_address1 | string | Optional | First line of the receiving site's address. |
| site_address2 | string | Optional | Second line of the receiving site's address. |
| site_city | string | Optional | City of the receiving site. |
| site_postcode | string | Optional | Postcode or ZIP of the receiving site. |
| site_state | string | Optional | State, province, or county of the receiving site. |
| site_country | string | Optional | Country of the receiving site. |
Custom Extensibility Fields
The GRN schema includes three groups of generic extensibility fields for carrying customer-specific metadata that does not map to a standard field. These are intended for organisations that need to pass additional context from their ERP through to SoftCo — for example internal reference codes, custom dates, or monetary values specific to their receiving process. Use only the fields your implementation requires; unused fields can be omitted.
| Field | Type | Required | Description |
|---|---|---|---|
| label1 through label9 |
string | Optional | Nine free-text label fields for carrying customer-specific string values — reference codes, status flags, classification tags, or any other text metadata your organisation needs to attach to the receipt.
e.g. label1: "URGENT"label2: "QC-PASSED"
|
| date1 through date3 |
string | Optional | Three date fields for customer-specific date values — for example expected put-away date, inspection date, or customs clearance date. Format: YYYY-MM-DD. |
| amount1 through amount3 |
numeric (decimal) | Optional | Three numeric amount fields for customer-specific monetary or quantity values — for example freight charges, insurance values, or customs duties associated with the receipt. Must be provided as a numeric value with up to 2 decimal places, without any thousand separators such as commas.
e.g. amount1: 45.00
|
Line Item Fields (rows array)
Line item fields are nested inside the rows array within the GRN record. Each element of the array represents one received line — with its own PO reference, quantity, unit of measure, and optional accounting coding. Every GRN must contain at least one line item.
The purchase order reference is carried on each individual line item, not on the GRN header. This allows a single delivery to acknowledge receipt of items from multiple purchase orders simultaneously. Ensure po_number and item_number on each row match the corresponding values on the originating purchase order exactly — SoftCo uses this combination to locate the specific PO line to update.
| Field | Type | Required | Description |
|---|---|---|---|
| Line Identification & PO Reference | |||
| row_id | string | Required | A unique identifier for this line in your system, typically internal row key from your ERP.
e.g. "1""2"
|
| line_number | numeric (integer) | Required | The line number corresponding to the received line in the GRN. This is a unique identifier for this line within the GRN — typically the line sequence number.
e.g. 12
|
| po_number | string | Required | The purchase order number this receipt line is fulfilling. Must exactly match the po_number on the corresponding purchase order sent via the Purchase Orders API.
e.g. "PO-2024-00891"
|
| system | string | Optional | Source system identifier at line level, for use where line items originate from a different system than the GRN header — for example a warehouse management system distinct from the main ERP. |
| Item Details | |||
| item_number | numeric (integer) | Required | The line number that corresponds to the matching line on the purchase order. SoftCo uses this together with po_number to identify which PO line is being fulfilled by this receipt.
e.g. 114
|
| item_description | string | Recommended | A description of the item or service received on this line. Carried through for display and context in SoftCo. Should correspond to the description on the purchase order.
e.g. "A4 Copy Paper — 5 Ream Box"
|
| Quantity & Unit of Measure | |||
| quantity_received | number (decimal) | Required | The quantity of the item received or the quantity of service confirmed on this line. SoftCo compares this against the ordered quantity on the PO line to determine whether the delivery is complete, partial, or over-received. For partial deliveries, send only the quantity received to date — subsequent GRNs can carry the remaining balance. Must be provided as a numeric value with up to 6 decimal places, without any thousand separators such as commas.
e.g. 102.5
|
| uom | string | Required | The unit of measure for the received quantity. Should match the unit of measure on the corresponding PO line.
"EA""BOX""KG""HR""DAY"
|
| Accounting Objects (accounting_object_1 – accounting_object_9) | |||
| accounting_object_1 through accounting_object_9 |
string | Optional | Up to nine accounting dimension values — cost centres, departments, projects, or other segmentation dimensions configured in SoftCo. These can be used to override or supplement the accounting coding carried on the purchase order line. Only populate the dimensions your organisation uses; unused fields can be omitted.
e.g. accounting_object_1: "CC-ADMIN"accounting_object_2: "PRJ-0042"
|
Example Requests
Single GRN with full shipping document detail
POST /goods-received/v1 x-api-key: your-api-key-here Content-Type: application/Json Client_Id: your-client-id Client_Secret: your-client-secret { "objects": { "object": { "record": [ { "organization": "main", "system": "NetSuite", "grn_number": "GRN-2024-04521", "grn_date": "2024-03-18", "received_by": "Ciara Brennan", "delivery_slip": "DS-ACM-20240318", "delivery_slip_date": "2024-03-18", "packing_slip_number": "PKG-44221", "grn_supplier_number": "SUP-001234", "grn_supplier_name": "Acme Office Supplies Ltd", "grn_supplier_city": "Dublin", "grn_supplier_country": "Ireland", "site_name": "Dublin Distribution Centre", "site_number": "SITE-003", "grn_comment": "All items received in good condition", "rows": [ { "row_id": "1", "line_number": 1, "po_number": "PO-2024-00891", "item_number": 1, "item_description": "A4 Copy Paper — 5 Ream Box", "quantity_received": 10, "uom": "BOX", "accounting_object_1":"CC-ADMIN" }, { "row_id": "2", "line_number": 2, "po_number": "PO-2024-00891", "item_number": 2, "item_description": "Printer Ink Cartridge — Black", "quantity_received": 5, "uom": "EA", "accounting_object_1":"CC-ADMIN" } ] } ] } } }
Multi-PO receipt — one GRN covering lines from two purchase orders
{ "objects": { "object": { "record": [ { "grn_number": "GRN-2024-04522", "grn_date": "2024-03-18", "grn_supplier_number": "SUP-001234", "received_by": "Ciara Brennan", "rows": [ { "row_id": "1", "line_number": 1, "po_number": "PO-2024-00891", "item_number": 1, "item_description": "A4 Copy Paper", "quantity_received": 10, "uom": "BOX" }, { "row_id": "2", "line_number": 2, "po_number": "PO-2024-00892", // different PO on same delivery "item_number": 1, "item_description": "IT Consulting Services — Day 1", "quantity_received": 1, "uom": "DAY" } ] } ] } } }
Batch — multiple GRNs in one request
{ "objects": { "object": { "record": [ { "grn_number": "GRN-2024-04521", "grn_date": "2024-03-18", "grn_supplier_number": "SUP-001234", "rows": [ { "row_id": "1", "line_number": 1, "po_number": "PO-2024-00891", "item_number": 1, "quantity_received": 10, "uom": "BOX" } ] }, { "grn_number": "GRN-2024-04523", "grn_date": "2024-03-18", "grn_supplier_number": "SUP-000876", "rows": [ { "row_id": "1", "line_number": 1, "po_number": "PO-2024-00892", "item_number": 1, "quantity_received": 8, "uom": "DAY" } ] } ] } } }
Validation
Every request is validated against the GRN schema before any processing takes place. If validation fails, the entire request is rejected immediately — nothing is queued or forwarded to SoftCo. You receive a clear error identifying the field or structural issue.
What is checked
| Check | Detail |
|---|---|
| Envelope structure | The payload must use objects → object → record as plain JSON objects. Using an array at the objects or object level will fail validation. |
| Required header fields | grn_number, grn_date, and grn_supplier_number must be present in every record. |
| rows array presence | Every GRN record must contain a row array containing at least one line item. |
| rows structure | rows must be a JSON array. Sending rows as a JSON object directly will fail validation. |
| Required line fields | Every row object must contain row_id, line_number, po_number, quantity_received, and uom. |
| Field types | Fields must match their declared types. Numeric fields (line_number, item_number, quantity_received) must be sent as JSON numbers, not strings. Sending the wrong type for any field will fail validation. |
| Non-empty required values | Required fields must not be empty strings. |
Validation error response
{ "status": "FAILED", "total": 1, "succeeded": 0, "failed": 1, "errors": [{ "index": 0, "error": "required key [grn_number] not found" }], "message": "1 of 1 records failed validation." }
Troubleshooting
The most common error scenarios and how to resolve them.
rows as a JSON object directly, rather than as a JSON arrray. The validation error may reference an unexpected type at the rows level."rows": [ ... ] }errors array will identify the missing field — for example required key [grn_number] not found or required key [grn_supplier_number] not found.grn_number, grn_date, and grn_supplier_number are present in every record object. None can be omitted or null.rows array holding at least one line item. Sending a record without rows: [], or with rows as an empty array will fail validation.rows array with at least one complete line item in every GRN record.po_number is required at the line level — not at the header — and is the field most often omitted by integrations migrating from header-level PO references. The errors array will reference the failing field.row_id, line_number, po_number, quantity_received, and uom. All five are required on each line and none can be omitted or null.Partial deliveries are fully supported. Each GRN submission sends the quantity received to date for each line. SoftCo accumulates receipt quantities across multiple GRN submissions and holds a matched invoice until the total receipted quantity satisfies the PO line. You do not need to send a single final GRN — submit each delivery as it occurs.
Example Responses
Success — 202 Accepted
{ "status": "SUCCESS", "total": 1, "succeeded": 1, "failed": 0, "errors": [], "message": "All records processed successfully." }
Partial success — 207 Multi-Status
{ "status": "PARTIAL", "total": 3, "succeeded": 2, "failed": 1, "errors": [{ "index": 1, "error": "required key [grn_supplier_number] not found" }], "message": "2 of 3 records processed successfully. 1 record failed validation." }
Validation failure — 400 Bad Request
{ "status": "FAILED", "total": 1, "succeeded": 0, "failed": 1, "errors": [{ "index": 0, "error": "required key [grn_supplier_number] not found" }], "message": "1 of 1 records failed validation." }
Authentication failure — 401 Unauthorized
{ "status": "FAILED", "message": "Unauthorized" }
What's Next
Goods Received completes the inbound transaction API set. Together with the Purchase Orders API, it enables full three-way matching in SoftCo — ensuring every invoice is validated against both a committed purchase order and a confirmed delivery before it can be approved for payment.