Overview
When a sync task fails, Junipeer logs an error with a specific error code and message. This guide lists all known error codes, explains what causes them, and provides resolution steps.
You can also look up errors directly in the new knowledge base at junipeer-kb.vercel.app/errors, which supports searching by error message and filtering by severity.
To find errors for a specific integration, use the Logs page in the Junipeer app and filter by status "error".
Fortnox Error Codes
COMMON_FORTNOX_ERRORS_EXPLAINED
Severity: Error
This is a grouped reference covering two of the most common Swedish-language Fortnox errors:
"Kunde inte hämta/hitta moms" (Could not retrieve/find VAT)
Cause: VAT rates are not configured in Fortnox.
Solution: In Fortnox, go to Settings → Bookkeeping → Moms (VAT) and create the missing VAT rate. Swedish defaults are 25%, 12%, and 6% — if your orders include other rates (e.g., from EU cross-border sales), those must be added manually.
"Kunde inte hämta/hitta valuta" (Could not retrieve/find currency)
Cause: The order currency is not enabled in Fortnox.
Solution: In Fortnox, go to Settings → Leverantörsfakturor → Valuta (Currency). Select the missing currency code and save. The currency name is added automatically.
FORTNOX_ACCOUNT_INACTIVE
Severity: Error Message: "The account is not active"
Cause: A product in Fortnox is linked to a bookkeeping account that has been deactivated. The account must be active for Fortnox to create invoices.
Solution: In Fortnox, go to Settings → Bookkeeping → Chart of Accounts. Find the account referenced in the error and reactivate it. Alternatively, update the product in Fortnox to use a different, active account.
FORTNOX_COST_CENTER_AUTH
Severity: Error Message: "Lacks authorization for cost centers"
Cause: The Fortnox user connected to Junipeer does not have the required license or permissions for cost centers. Cost centers are one of the first things Fortnox checks on connection, so this error can appear even if you do not actively use cost centers.
Solution: In Fortnox, go to Settings → Manage Users. Verify the integration user has the correct license type that includes cost center access. This may require upgrading the user's Fortnox license. See the Fortnox Setup guide for the full list of required permissions.
FORTNOX_CURRENCY_MISMATCH
Severity: Error Message: "Currency X and Currency X does not match"
Cause: During payment reconciliation, the payment currency and the invoice currency are different. Fortnox requires that the payment and invoice use the same currency.
Solution: This typically happens when a payout is settled in a different currency than the original order. Check the invoice in Fortnox to verify its currency, and verify that the payment provider payout report uses the same currency. If currencies legitimately differ, you may need to handle reconciliation manually for those transactions.
FORTNOX_CURRENCY_NOT_FOUND
Severity: Error Message: "Could not retrieve/find currency"
Cause: The order uses a currency that is not configured in Fortnox.
Solution: In Fortnox, go to Settings → Leverantörsfakturor → Valuta and enable the missing currency. Then retry the failed task in Junipeer from the Tasks page. To prevent this in the future, enable all currencies your e-commerce platform supports before going live.
FORTNOX_CUSTOMER_NAME_EMPTY
Severity: Error Message: "Customer name cannot be empty (2000637)"
Cause: The order in the e-commerce platform has no billing address or customer name. Fortnox requires a customer name on all orders and invoices.
Solution: Configure a default customer name in Junipeer under Configure > Settings > Customer Settings. This fallback value will be used whenever an order arrives without a customer name (common with guest checkout or marketplace orders). You can also update the order in the e-commerce platform to add a customer name and retry the sync.
FORTNOX_FISCAL_YEAR
Severity: Error Message: "Fiscal year not available"
Cause: The order date falls in a fiscal year that has not been created in Fortnox. Fortnox requires an active fiscal year for any date on which transactions are booked.
Solution: In Fortnox, go to Settings → Bookkeeping → Fiscal Year and create the missing fiscal year. This commonly occurs at the start of a new calendar year if the next year's fiscal period has not been set up yet. After creating the fiscal year, retry the failed tasks.
FORTNOX_PAYMENT_DATE
Severity: Error Message: "The payment date cannot precede the invoice date"
Cause: During payment reconciliation, the payment date recorded by the payment provider is earlier than the invoice date in Fortnox. Fortnox does not allow a payment to be registered before the invoice exists.
Solution: This usually happens when there is a timing gap — the customer pays immediately, but the invoice is created in Fortnox later (e.g., due to a sync delay or batch processing). Junipeer uses the following date priority order when determining payment dates:
Payment provider date (highest priority)
Order date
Sync date (lowest priority)
If this error occurs frequently, check whether your scheduling runs often enough to keep invoice creation close to order placement. You may also need to adjust the payment date logic in consultation with Junipeer support.
FORTNOX_SHIPPING_NOT_FOUND
Severity: Error Message: "Kunde inte hämta/hitta leveranssätt" (Could not retrieve/find shipping method)
Cause: A shipping method that was previously configured in Fortnox has been removed or deactivated, but is still referenced on a customer record. This is a known Fortnox behavior — deleting a shipping method does not clean up existing references to it.
Solution: In Fortnox, find the affected customer record and update or remove the shipping method reference. Alternatively, re-create the deleted shipping method in Fortnox. Also verify your shipping method mappings in Junipeer under Configure > Settings > Shipping Methods to ensure all active e-commerce shipping methods are mapped.
FORTNOX_VAT_NOT_FOUND
Severity: Error Message: "Kunde inte hämta/hitta moms" (Could not retrieve/find VAT)
Cause: The VAT rate on the incoming order is not configured in Fortnox. By default, Fortnox only has 25%, 12%, and 6% (standard Swedish rates).
Solution: In Fortnox, go to Settings → Bookkeeping → Moms (VAT) and create the missing VAT rate. If you sell cross-border within the EU, you may need to add VAT rates for each destination country (e.g., 21% for Netherlands, 19% for Germany). See the Fortnox Setup guide for details on OSS sales account configuration.
General Error Codes
ERROR_MESSAGE
Severity: Error Message: "Error message:" (followed by details)
Cause: A product number, order field, or other data value contains excessively long or incorrectly formatted text. This is a general data validation error that occurs when a field exceeds the maximum length allowed by the target system.
Solution: Check the entity referenced in the error (visible in Logs). Look for unusually long product names, SKU numbers, or custom field values that may exceed the target system's field length limits. Shorten the value in the source platform and retry the sync.
Additional Error Patterns
The following errors are not listed as formal error codes in the knowledge base but appear frequently in real-world support cases.
"Invalid grant"
Systems: Fortnox, Visma.net (OAuth-based connectors) Severity: Critical
Cause: The OAuth token for a connector has expired or been revoked. All syncs stop until the connection is re-established.
Solution: Go to Connectors, disconnect the affected connector, and reconnect by re-authorizing through the OAuth flow. If the problem recurs frequently, check whether the token expiration policy has changed on the platform side.
"Customer ID not found"
Systems: Fortnox, Business Central, Visma.net (any ERP destination) Severity: Error
Cause: An order references a customer that does not exist in the target ERP. This can happen when customer sync is not enabled or when a customer was created in the e-commerce platform after the last customer sync ran.
Solution: Ensure the customer sync flow is enabled and has run recently. You can also manually trigger an Export One for the missing customer, then retry the order sync. If the customer already exists in the ERP under a different ID, check the References page.
"Cash account not found"
Systems: Fortnox, Visma.net (ERP destination) Severity: Error
Cause: A payment method is mapped to a cash account in the ERP that Junipeer cannot resolve, even though it appears in the account list. This can occur when the ERP's API returns accounts that are not fully activated or configured.
Solution: Try mapping to a different cash account to confirm the sync works, then investigate the original account in the ERP. The account may need to be fully activated or its API visibility settings may need adjustment. Contact Junipeer support if the issue persists.
"Could not json-decode visma error response"
Systems: Visma.net (ERP) Severity: Error
Cause: Visma.net returned an error response that Junipeer could not parse. This typically indicates an unexpected API change or a server-side issue on Visma.net's end.
Solution: Retry the sync. If the error persists, check whether Visma.net is experiencing downtime or has released an API update. Contact Junipeer support with the task ID for investigation.
"Order with ID X not found"
Systems: Shopify, Centra, Magento, Norce (e-commerce source platforms) Severity: Error
Cause: Junipeer is trying to load an order from the e-commerce platform, but the order does not exist or is not accessible. This can happen if an order was deleted, archived, or if the API credentials lack access to that specific order scope.
Solution: Verify the order exists in the source platform and is accessible via the API. If the order was deleted, it cannot be synced. If it exists but Junipeer cannot find it, check API permissions and scope.
"Could not identify the size in the product attributes"
Systems: Business Central / Trimit (ERP) → Centra (e-commerce) Severity: Error
Cause: When syncing products, Junipeer cannot match a product's size attribute to the configured size chart. The size value in the source system does not correspond to any entry in the mapped size chart.
Solution: Check the product's size attribute in the source system and verify it matches the size chart mapping in Junipeer's Article settings. If a new size chart was created, it may need to be added to the mapping configuration.
Cached data preventing re-sync
Systems: All platforms (Junipeer internal) Severity: Info
Cause: A record was corrected in the source platform (e.g., a bad postal code was fixed), but Junipeer still has the old, cached version and continues to fail.
Solution: Use the Clear Cache button on the Configure > Settings page to force Junipeer to fetch fresh data from the source platform. Then retry the failed task.
Orders missing from sync without errors
Systems: All e-commerce platforms (source) Severity: Warning
Cause: Some orders may not appear in Junipeer at all — no task, no log entry, no error. This can happen when the order falls outside the Time History window or the order exclusion date, or if there was a brief connectivity gap during a scheduled sync.
Solution: Check the Time History page to confirm the "last loaded" date covers the missing order's creation date. If the date range looks correct, manually trigger an Export One for the specific order from the Flows page. If the order still does not appear, contact Junipeer support with the order ID.
Token expiration
Systems: All OAuth-based connectors (Fortnox, Visma.net, Shopify, Business Central) Severity: Critical
Cause: API tokens or OAuth connections can expire over time. When this happens, all syncs for that connector fail simultaneously.
Solution: Reconnect the affected connector on the Connectors page. To prevent surprise outages, monitor for sudden spikes in stopped tasks on the Dashboard — a jump from near-zero to all-failing is a strong indicator of an expired token.
Duplicate SKUs causing incorrect stock sync
Systems: Centra (source), any ERP (destination) Severity: Error
Cause: In Centra, a single SKU can be associated with multiple products — for example, if products are duplicated across seasons or collections. When Junipeer queries stock by SKU and receives multiple results, it may sync stock from the wrong product (inactive or cancelled) instead of the active one.
Solution: Ensure each SKU is unique to a single active product in Centra. If duplicate SKUs exist due to seasonal collections, deactivate or cancel the old product entries in Centra. Junipeer prioritizes active products when available, but ambiguous SKU mappings can still cause issues. Contact Junipeer support if you need custom SKU resolution logic.
"Loaded 0 Articles" — product not found in ERP
Systems: Business Central, Visma.net (source ERP → e-commerce destination) Severity: Error
Cause: When trying to sync a product, Junipeer loads zero articles from the ERP. The product may not exist, may be unpublished, or may be missing required fields that prevent it from being returned by the API.
Solution: Verify the product exists in the ERP and has all required fields populated. In Visma.net, check that the article has a name — the error "The Product Name attribute value is empty" indicates a missing name field. In Business Central, verify the product is published and accessible via the integration API endpoint.
"Too many requests" — rate limiting on large syncs
Systems: Centra, Brightpearl, and other platforms with strict API rate limits Severity: Error
Cause: High-volume syncs (e.g., a full stock sync with thousands of SKUs) exceed the target platform's API rate limits. The task partially completes and then fails with rate-limiting errors.
Solution: Reduce the sync frequency in Scheduling — for example, change from every 1 minute to every 5 minutes. For initial data loads, sync in smaller batches using date ranges. If the error persists, contact Junipeer support to adjust API throttling settings.
Multi-warehouse stock sync issues
Systems: Business Central / Trimit (ERP) → Centra (e-commerce) Severity: Error
Cause: When multiple warehouses are configured, stock sync may report "no changes" even when stock levels differ between the ERP and e-commerce platform. This typically occurs when warehouse location codes in Business Central are not correctly mapped, or when the default warehouse configuration does not match the ERP's warehouse structure.
Solution: In Junipeer, go to Configure > Settings and verify your warehouse mappings. Ensure each warehouse ID in Business Central is correctly mapped to the corresponding warehouse in Centra. After adjusting mappings, use Clear Cache on the flow settings page and retry the stock sync.
"Could not create reference"
Systems: Junipeer (References page), any connector pair Severity: Error
Cause: When manually creating entity references (cross-system ID mappings) in the References page, the operation fails. This can happen if the entity IDs do not exist in one or both connected systems, or if there is a data type mismatch between the source and target ID formats.
Solution: Verify that both the source and target IDs exist in their respective systems. Check that the IDs are in the correct format (some systems use numeric IDs, others use alphanumeric). If the error persists, contact Junipeer support with the specific reference IDs you are trying to create.
SAP Business One — order status detection issues
Systems: SAP Business One (ERP) Severity: Warning
Cause: SAP Business One's Service Layer API does not always clearly distinguish between cancelled, closed, and fulfilled orders. The DocumentStatus: bost_Close flag can apply to both completed and cancelled orders, and the Cancelled flag may not be set even when an order was cancelled in the SAP GUI. This can cause Junipeer to misinterpret order statuses.
Solution: Contact Junipeer support to verify the order status mapping for your SAP Business One setup. The team may need to adjust the mapping logic based on your specific SAP configuration and workflows.
SAP Business One — stock timestamp not updating
Systems: SAP Business One (ERP) Severity: Warning
Cause: The item UpdateDate/UpdateTime fields in SAP Business One are not always updated when stock changes occur through transactions like goods receipts or shipments. This causes Junipeer's date-based stock sync to miss changes.
Solution: Junipeer has implemented alternative stock change detection for SAP Business One that does not rely on item timestamps. If you are experiencing missed stock updates, contact support to ensure you are using the latest connector version with improved stock tracking.
"Ignoring order — no reference found"
Systems: Business Central / Trimit (ERP) → Centra (e-commerce) Severity: Error
Cause: When Junipeer tries to update an order's status (e.g., marking it as shipped), it cannot find the matching reference in its mapping table. This typically happens in Business Central by Trimit integrations where sales documents are converted to sales orders and then posted, changing their document IDs through the process.
Solution: Check the References page to verify the order mapping exists. If the reference is missing, it may need to be created manually. In complex ERP workflows where documents change IDs through processing stages, contact Junipeer support to verify the reference tracking logic.
"Cannot update customer in Visma" error
Systems: Visma.net (ERP) Severity: Error
Cause: When syncing customer data to Visma.net, the update fails due to field validation errors or permission restrictions in the Visma.net API.
Solution: Check the specific error message in the Logs for field-level details. Common causes include invalid country codes, missing required fields, or the customer record being locked for editing in Visma.net. Verify the customer data in the source system and retry.
Visma Business — incorrect unit of measure synced
Systems: Visma Business (ERP) → e-commerce platforms Severity: Error
Cause: The integration syncs the wrong unit of measure from Visma Business — for example, pulling "packages" instead of "skeins" for yarn products. This can happen when the product's primary unit field in Visma Business is configured differently than expected, or when the integration reads a secondary unit field.
Solution: Verify the product's unit of measure configuration in Visma Business. Ensure the primary unit field matches what should be synced to the e-commerce platform. Contact Junipeer support if the integration is reading the wrong unit field.
Credit memo VAT handling mismatch
Systems: Business Central (ERP), Centra (e-commerce) Severity: Warning
Cause: The credit note/refund flow may not respect the same "VAT included in order rows" setting that the order flow uses. If orders are configured with VAT-inclusive pricing but credit memos are not, the refund amounts may be incorrect.
Solution: Verify that the credit memo flow settings match the order flow settings for VAT handling. Check Configure > Settings for the credit memo flow and ensure VAT inclusion settings are consistent. Contact Junipeer support if the setting is not available on the credit memo flow.
Webhook signal not received — manual trigger button fails
Systems: Visma.net → nShift (via Junipeer), any webhook-triggered flow Severity: Warning
Cause: The source ERP has a button or action (e.g., "Send to nShift" in Visma.net) that triggers a webhook to Junipeer. If the webhook signal does not arrive, the shipment is not synced. This can happen due to temporary Visma.net API issues, webhook delivery failures, or the button not being properly configured in the ERP.
Solution: First, check the Tasks page to see if a task was created — if not, the signal never reached Junipeer. As a workaround, use the Export One button on the Flows page to manually sync the shipment. If the webhook button regularly fails, contact Junipeer support to investigate adding webhooks programmatically or switching to a polling-based schedule.
Overselling during high-volume sales — stock sync lag
Systems: Visma.net (stock master) → Centra (e-commerce), any ERP → e-commerce stock sync Severity: Warning
Cause: During flash sales or high-traffic events (e.g., 15 orders per minute), the default 5-minute stock sync interval is too slow. The ERP has the correct stock, but by the time Junipeer syncs it to the e-commerce platform, multiple orders have already been placed for out-of-stock items.
Solution: Temporarily reduce the sync interval in Scheduling — e.g., from 5 minutes to 1 minute during peak periods. For a more permanent fix, enabling webhooks on both the ERP and e-commerce side provides near-real-time stock updates. Contact Junipeer support to discuss webhook-based stock sync if overselling is a recurring issue.
OSS VAT country mapping request — taxZone and taxCategory
Systems: Centra → Visma.net (ERP), any OSS-enabled flow Severity: Info
Cause: When merchants begin reporting OSS (One Stop Shop) VAT, they need country-specific tax zone and tax category mappings. For example, a French order should map to taxZoneId: FR and taxCategory: FR in Visma.net. This requires custom mapping configuration that may not be available in the default settings UI.
Solution: OSS country-to-tax mapping requires custom configuration. Contact Junipeer support with your requirements. If possible, request that changes be deployed to a QA/test environment first before going live to avoid accounting disruptions. For Fortnox integrations, OSS is handled through the sales account mapping feature in the platform UI.
Shopify manual/draft orders exported as paid instead of unpaid
Systems: Shopify → Fortnox Severity: Error
Cause: When merchants create manual or draft orders in Shopify for B2B invoicing, the orders may be incorrectly marked as paid in Fortnox. This happens because the default flow treats all orders as paid, which is correct for B2C but wrong for manual orders intended for invoice-based payment terms (e.g., 14 or 30 days).
Solution: Use Shopify order tags (e.g., FN14, FN30) to indicate payment terms, and configure Junipeer's rule builder to detect these tags and set the appropriate payment terms in Fortnox while keeping the invoice unpaid. Contact Junipeer support for help configuring this flow, as it requires mapping adjustments in the Transform Fortnox Orders to Invoices endpoint.
Incorrect payout references after activating new payment provider
Systems: Shopify → Fortnox (with Mollie, Qliro, or other PSPs) Severity: Error
Cause: When a new payment provider (e.g., Mollie) is activated in Shopify without first configuring it in Junipeer, historical payouts receive incorrect references in Fortnox. New orders work fine, but payouts created before the configuration was added contain wrong reference data.
Solution: Always configure new payment providers in Junipeer before activating them in Shopify. If already activated, contact Junipeer support to correct the historical payout references. Going forward, Junipeer will map the new provider correctly for all new orders.
Qliro payouts not syncing with Fortnox invoices
Systems: Shopify → Fortnox (Qliro payment provider) Severity: Critical
Cause: Qliro-paid invoices show as unpaid in Fortnox even though payments were collected. The payout reconciliation flow fails to match Qliro payouts to the corresponding Fortnox invoices, resulting in hundreds of invoices appearing as outstanding.
Solution: Check the Export Payouts to Fortnox flow in Flows and verify that the Qliro payout mapping is correctly configured. If the issue affects a large number of invoices, contact Junipeer support — batch correction may be needed to reconcile historical payouts.
Refund missing discount row on credit invoice
Systems: Centra → Fortnox (refund/credit flow) Severity: Error
Cause: When refunding an order that had a discount applied, the credit invoice in Fortnox only includes the product row but not the discount row. This causes the credit invoice amount to be higher than the actual refund amount (e.g., product was 2660 SEK minus 880 SEK discount = 1730 SEK refund, but credit invoice shows 2660 SEK).
Solution: Contact Junipeer support. The refund mapping needs to be updated to include discount/credit rows alongside product rows when generating credit invoices.
Refund created as invoice instead of credit invoice
Systems: Svea → Fortnox, any refund flow Severity: Critical
Cause: Refunds from the payment provider are being created as standard invoices in Fortnox rather than credit invoices, causing incorrect accounting entries and VAT discrepancies.
Solution: Contact Junipeer support immediately. The refund-to-invoice mapping must be corrected to use the credit invoice document type in Fortnox.
Return fee treated as shipping on credit invoice
Systems: Centra → Fortnox Severity: Error
Cause: In the credit invoice, a return fee (e.g., 39 SEK) is incorrectly categorized as "Shipping" instead of "Fee", causing it to be booked to the shipping account (e.g., 3520) instead of the fee account (e.g., 3002).
Solution: Verify your fee account and shipping account mappings in Configure > Settings for the refund flow. The return fee mapping may need adjustment — contact Junipeer support if the fee is not being mapped to the correct account category.
Refund payout amount doubled (negative balance)
Systems: WooCommerce → Fortnox (Walley payment provider) Severity: Error
Cause: During payout reconciliation, the refund amount is applied twice — once as a negative payout and once as a refund deduction — resulting in a double negative balance on the invoice in Fortnox.
Solution: Contact Junipeer support with the specific order and payout IDs. This is typically a mapping issue in how refund payouts are handled for the specific payment provider.
"Could not map payout transaction" — multi-market currency mismatch
Systems: Shopify → Fortnox (multi-market stores) Severity: Error Message: "Could not map payout transaction: Invoice X, Unsupported currency combination"
Cause: In Shopify stores with multiple markets (e.g., domestic SEK + international EUR), payouts from one market may contain transactions in a currency that doesn't match the invoice currency in Fortnox. The payout reconciliation fails because it cannot match cross-currency transactions.
Solution: Contact Junipeer support. Multi-market payout reconciliation requires special configuration to handle currency conversions between the payout currency and invoice currency.
EU Reverse Charge not applied — WooCommerce VAT number in meta field
Systems: WooCommerce → Fortnox Severity: Error
Cause: B2B orders from EU customers are charged VAT instead of being handled as reverse charge. This happens because WooCommerce does not have a standard VAT number field — the number is stored in a custom meta field via a plugin, and Junipeer cannot detect it without custom mapping.
Solution: Contact Junipeer support to configure custom VAT number mapping from the WooCommerce meta field. Once configured, orders with a valid EU VAT number will be correctly classified as reverse charge in Fortnox.
OSS sales account mapping not applied to credit notes
Systems: Centra/Shopify → Fortnox (OSS-enabled) Severity: Error
Cause: The OSS sales account mapping works correctly for invoices but does not apply to credit notes with new order rows. This means refunds for international orders may be booked to the wrong sales account, breaking country-specific VAT reporting.
Solution: Contact Junipeer support. The credit note flow needs to be updated to inherit the same OSS sales account mapping logic as the invoice flow. This is typically an issue with the VATCode or Project fields not being carried over to the credit invoice rows.
Scheduled sync reports success but transfers 0 records
Systems: Magento → Fortnox, any scheduled flow Severity: Warning
Cause: The scheduled sync runs and reports "Completed" status with 0 records processed. The task technically succeeds (no errors), but no data is actually transferred. This can happen when the time window cursor gets stuck, the source API silently returns empty results, or a filter configuration excludes all records.
Solution: Check the Time History page to verify the sync window hasn't jumped past the available data. Also check flow filters to ensure they're not too restrictive. Try running an Export Many with a specific date range to confirm data is available. If the issue persists, contact Junipeer support — the sync cursor may need to be reset.
Order status filter not working
Systems: Shopify → Fortnox, any flow with status filters Severity: Error
Cause: A flow configured to sync orders with specific statuses (e.g., FULFILLED) is not processing matching orders. The filter appears correctly configured in the UI but orders are being skipped.
Solution: Check the filter configuration on the flow settings page (gear icon → Source → Filters). Verify that the status values match exactly (case-sensitive). If the filter looks correct but orders are still skipped, use Export One to manually sync a specific order to confirm the issue. Contact Junipeer support if the filter appears to be malfunctioning.
Visma Business — customer number allocation error
Systems: Centra → Visma Business (ERP) Severity: Error Message: "Det var inte mulig å allokere nummer fra den angitte nummerserie" (Could not allocate number from the specified number series)
Cause: When creating a new customer in Visma Business for an incoming order, the number series for customer IDs has been exhausted or is misconfigured. Visma Business cannot assign a new customer number.
Solution: In Visma Business, check the number series configuration for customers. The series may need to be extended or a new series created. This is an ERP-side configuration issue — contact your Visma Business administrator.
Sync stops after processing 700–900 records
Systems: WooCommerce → Fortnox, any high-volume flow Severity: Error
Cause: During large batch syncs, the process stops after processing approximately 700–900 records without a clear error. This can be caused by memory limits, API pagination issues, or timeout thresholds being reached.
Solution: Split large syncs into smaller batches using date ranges via Export Many. If the issue persists, contact Junipeer support to investigate potential pagination or memory issues with the connector.
NoWaste → Norce shipment sync JSON parsing error
Systems: NoWaste → Norce Severity: Error Message: "json: cannot unmarshal number 1.0 into Go struct field PickReportEventBody.body.event_data.NumberOfPallets of type int"
Cause: The NoWaste webhook sends a decimal number (1.0) for the NumberOfPallets field, but the integration expects an integer. This type mismatch causes the JSON parsing to fail.
Solution: Contact Junipeer support. This is a connector-level fix that requires updating the data type handling for the NoWaste webhook payload.
Duplicate invoices for the same order
Systems: Shopify → Fortnox, any order-to-invoice flow Severity: Error
Cause: The same order is invoiced twice in Fortnox. This can happen when a webhook fires multiple times for the same event, or when a manual Export One is triggered for an order that was already processed by a scheduled sync.
Solution: Check the References page to see if duplicate references exist for the order. Junipeer normally prevents duplicate processing by checking references, but edge cases (e.g., timing between webhook and schedule) can cause duplicates. Delete the duplicate invoice in Fortnox and contact Junipeer support if it recurs.
Rounding/currency discrepancies leaving small unpaid amounts
Systems: Shopify/Centra → Fortnox, any invoice flow Severity: Warning
Cause: Due to currency conversion rounding differences between the e-commerce platform and Fortnox, invoices may have tiny unpaid amounts (e.g., 0.01 SEK) after payment reconciliation. Over time, these accumulate into many invoices appearing as "unpaid" despite being fully collected.
Solution: Junipeer has implemented rounding correction logic for new invoices. For existing invoices with small discrepancies, contact Junipeer support — batch correction may be available. In Fortnox, you can also use the "write-off" feature to clear small remaining amounts on individual invoices.
Payout fee and write-off handling
Systems: Shopify/Centra → Visma.net (payout reconciliation) Severity: Info
Cause: When processing payouts from payment providers (Shopify, Adyen, Mollie, etc.), the payout amount includes transaction fees deducted by the PSP. These fees need to be recorded as write-offs in the ERP to balance the books.
Solution: Junipeer handles payout fees automatically by recording the net payout amount and the fee as a balance write-off using a configured write-off reason code. Ensure the FeeWriteOffReasonCode setting is configured in your integration. Note: Adyen does not currently provide a complete payout API, so Adyen payout reconciliation may not be available for all merchants.
General Troubleshooting
For troubleshooting common errors, see the Error Codes page or your connector pair's troubleshooting section.
Tips
When investigating an error, start with the Logs page and filter by the reference number of the failed record. This shows the full error trail for that specific entity.
Most errors can be resolved by fixing configuration and retrying the task — you rarely need to re-trigger the entire sync.
If the same error code appears on many tasks simultaneously, it usually indicates a configuration issue (missing currency, missing VAT rate) rather than a problem with individual records. Fix the configuration once and retry all failed tasks.
Errors in Swedish (e.g., "Kunde inte hämta/hitta...") come from the Fortnox API and are passed through by Junipeer. The error code reference on the Errors page includes translations and solutions for these.