Fix Sage 50 Remote Data Access connection failures

Identify the failure before applying a fix

A remote user cannot connect to the shared company, Sage reports the RDA service unavailable, or the remote site cannot apply the latest data.

Record the complete message, affected organisation or company, user, date range, and last successful action. A precise symptom is more useful than trying several broad repairs at once.

Checks before changing data

• Capture the complete error and identify every affected site.
• Confirm Sage’s service status and internet connectivity at the data-holding and remote sites.
• Back up data at each site before any reset or reupload operation.

Resolution path

1. Check the user and service state. Verify the user is allowed Remote Data Access and signs in with the expected Sage account.
   • Confirm the invitation and email address.
   • Check whether one user or every remote user is affected.
2. Check versions and local data service. Keep the sites on supported compatible Sage 50 versions and restart the documented Sage data services where the data is held.
   • Do not upgrade only one machine in the middle of an active recovery without the product’s upgrade plan.
   • Retest after the service restart.
3. Rule out the connection path. Use a stable wired internet connection where possible and verify firewall or endpoint security is not blocking Sage.
   • Test both the data-holding site and affected remote site.
   • Do not disable security controls globally.
4. Reset RDA only as a controlled final step. If Sage’s specific error guidance requires reset, disconnect all sites, preserve user details, remove and reupload once, then reconnect sites deliberately.
   • Back up every site first.
   • Stop all concurrent posting until the authoritative copy is established.

Verify the result

A disappearing error is not enough. Confirm the accounting and workflow outcome:

• Authorised users can open the current shared company.
• All sites see the same latest changes.
• Backups and reset notes identify the authoritative dataset.

What to avoid

• Resetting RDA before checking status, user access, and services.
• Letting multiple sites keep posting during a reset.
• Choosing an upload or download direction without deciding which copy is authoritative.

When to involve product support, IT, or your accountant

Stop making changes and escalate when any of these conditions applies:

• Sites contain conflicting unsynchronised changes.
• The service is available but reset fails.
• You cannot identify the current authoritative dataset.

Bring the exact error, screenshots, affected record IDs, timestamps, product version or region, and a description of every change already attempted. That evidence shortens the support path and reduces repeated or conflicting fixes.