Prima and InRiver
Integration Agency & Consultants
Inaccurate product data between InRiver and Prima usually becomes a bottleneck when teams try to scale SKU counts or launch new ranges across multiple channels. At low volume, manual data entry can bridge the gap between a marketing catalogue and an ERP. At scale, inconsistent attribute mapping creates financial reconciliation debt and inventory blind spots. We connect InRiver enriched product data to Prima ERP to establish a clear ownership boundary, ensuring that enriched marketing content reflects accurately in your core operational and financial records.
Auditing your ERP and PIM systems
Cogent2 connects your Prima and InRiver integration swiftly, ensuring your ERP and PIM systems work together efficiently. Our consulting services are invaluable, with our system audit services providing a thorough review of your Prima, InRiver, ERP, and PIM integrations. This enables our consultants and your team to identify and resolve inefficiencies, keeping your tech ecosystem running smoothly. By addressing integration gaps and optimising workflows, we help you deliver a great experience to your customers and support your business’s ongoing success.
Solution Design
Design decisions for Prima and InRiver focus on the tension between detailed product enrichment and core financial control. In most setups, we establish InRiver as the master for the PIM entity, where attributes are staged and validated before being pushed to Prima as core inventory records. A primary trade-off involves sync frequency. While a real-time push for every attribute change ensures parity, it can introduce instability in the ERP during bulk catalogue updates. We typically recommend a batched approach for heavy enrichment cycles to protect Prima’s inventory stability. This design ensures that product data is validated before it hits the financial system. The operating model relies on InRiver for enrichment and Prima for the operational and financial truth of the SKU.
Mapping data ownership between PIM and ERP
This integration maps InRiver product entities directly to Prima inventory records. Data originates in the PIM, where the ecommerce team manages specifications and enrichment. Once an entity crosses a defined readiness gate, the integration pushes these attributes to Prima to create or update SKUs. Mapping internal records accurately is critical to ensure inventory levels and sales orders remain tied to the correct financial objects. We embed monitoring at the boundary to catch attribute mismatches or incomplete records before they reach the ERP. This prevents operational blind spots during fulfilment or financial close by ensuring every SKU in Prima is backed by enriched, validated data from InRiver. Flow typically moves from the PIM to the ERP for master product data.
Secure orchestration via certified integration platforms
Leveraging IPaaS with SO 27001 and SOC 2 and above security accreditations, Prima and InRiver integrations are delivered efficiently and securely. IPaaS connects ERP and PIM systems, automating data flow between Prima, InRiver, ERP, and PIM platforms. This approach reduces manual effort, increases reliability, and ensures compliance, while providing a robust, centralised framework for managing integrations and safeguarding sensitive data.
Surfacing attribute errors and sync exceptions
Visibility in a Prima and InRiver integration means identifying errors before they affect operations. Hidden issues, such as missing attributes in InRiver causing incorrect records in Prima, can cause problems for months if undetected. Our platform identifies these exceptions by monitoring the integrity of each product record as it moves between systems. We surface alerts that show exactly which SKU is affected and what data is missing. This allows your team to fix the issue at the source in InRiver before it creates inventory or financial reporting gaps in your ERP.
Enabling teams to manage product lifecycles
Handover ensures the ecommerce and operations teams own the product lifecycle from enrichment to sale. We train ecommerce staff on staging data in InRiver and operations on how that data materialises as SKU records in Prima. Training defines daily checks for sync success and reviews of attribute consistency. Finance teams are shown how to verify that product mappings in the ERP align with inventory valuation needs. We provide an operational manual that details who owns specific exceptions, such as failed attribute mappings or incomplete product sets. This documentation is a practical guide for the people running the business, focused on resolving day-to-day data gaps rather than technical system theory.
Managing data drift and operational exceptions
Our support model focuses on preventing operational drift between your product catalogue and ERP. We monitor for sync failures, attribute mismatches, and SKU creation errors that would otherwise block stock intake or order fulfilment in Prima. If a product update fails to post to the ERP, our team identifies the mapping error or missing mandatory field before it impacts the financial close. By surfacing these exceptions through operational monitoring, we resolve data discrepancies before they compound into reconciliation debt, ensuring your technical architecture supports stable trading.
Common failures
Incomplete product data propagation
Operational impact: When a new SKU is synced from InRiver without all data required by Prima, such as a nominal code or tax category, it becomes unusable. This blocks the creation of Sales Orders for that SKU, preventing the fulfilment team from dispatching goods and forcing finance to perform manual corrections on related journal entries. Customer service must then manage inquiries for orders that are valid on the sales channel but blocked in the ERP.
Prevention / Action: The integration must perform a pre-flight validation check before sending any new product record from InRiver to Prima. This logic should confirm the presence and correct format of all mandatory fields. Records failing validation should be routed to an exception queue with automated alerts to the data governance or merchandising team responsible for product enrichment in InRiver.
Unmanaged product archival or deletion
Operational impact: If a product is archived in InRiver but the SKU remains active in Prima, it creates a ghost record in the ERP. This inflates internal product catalogues and can lead to accidental purchasing of discontinued stock. For the finance team, inventory valuation reports may contain SKUs that are no longer commercially active, distorting financial statements.
Prevention / Action: Define a clear product state model (for example: Active, Inactive, Discontinued) that is mapped between InRiver and Prima. The integration logic must monitor for these status changes in InRiver and trigger the corresponding update in Prima. Direct deletion in the ERP should be avoided; changing an SKU's status to 'inactive' preserves historical transaction data required for financial audits while preventing its use in new Sales Orders.
Mismatched identifiers creating duplicate stock records
Operational impact: If the integration does not use a single, immutable identifier, an update from InRiver can create a new duplicate SKU in Prima instead of amending the existing one. This splits inventory counts, sales history, and financial data across multiple records. Consequently, stock levels become inaccurate, leading to overselling and order cancellations, while the finance team struggles to reconcile cost-of-goods-sold and inventory valuation.
Prevention / Action: Establish a permanent, shared 'SKU' or 'Item Code' as the master key for each product in both InRiver and Prima from the point of creation. All subsequent updates sent by the integration must use this key exclusively. The integration design should include rules to reject any create or update instructions that do not use the agreed identifier, logging an exception for immediate technical review.
Frequently asked questions
Does deleting a product in InRiver remove it from Prima?
Not automatically. Deleting a product entity in InRiver typically does not trigger a deletion in Prima to protect sales history and stock records. The integration usually requires a specific rule to deactivate the Item record or flag it for archival in the ERP. This prevents obsolete SKUs from disrupting stock reporting or causing order processing errors.
Which attributes are mandatory for Prima to accept an InRiver record?
Prima requires specific operational data to create an Item record. This usually includes a unique SKU, unit cost, default tax code, and supplier information. If these are missing in InRiver, the sync will fail. We map these mandatory fields to ensure a product created by the marketing team is immediately usable for inventory and sales orders.
Can we split ownership between InRiver for marketing and Prima for stock?
Yes, this is the standard operating model. InRiver acts as the master for rich product descriptions, specifications, and assets. Once synchronised, Prima becomes the source of truth for live inventory levels, transactional pricing, and cost valuations. This removes source-of-truth ambiguity between the commercial and warehouse teams.
Why not manage all product data directly in Prima?
Prima is built for financial integrity and transactional speed, not complex catalogue enrichment. Managing marketing attributes in an ERP often leads to workflow fractures where commercial teams struggle to update channels. Using InRiver for enrichment and Prima for core SKU data ensures your teams use the right tool for their specific operational goals.