Last updated 12 September 2026
AcuTidy has write access to a customer's ERP master data. That is a serious thing to be trusted with, and the design decisions below follow from taking it seriously. This page describes how the product actually works, not how we aspire for it to work.
You connect AcuTidy by registering an OAuth application inside your own Acumatica instance and authorizing it. AcuTidy receives a token, not a username and password, and you can revoke that authorization from Acumatica at any time without involving us.
Nothing is installed inside your Acumatica. The only footprint is the OAuth application you register yourself.
Before anything is written, AcuTidy shows you a preview and a field-level difference report. When you confirm, the entire change set is recorded to our database before the first record is sent to Acumatica, and each change stores the value that was there before it. Undo replays those values back.
If a field has been changed in Acumatica by someone else since you started, AcuTidy refuses to overwrite it and reports it rather than silently discarding their work. The same check protects undo.
Acumatica offers no way to tell a sandbox from a production instance, so a newly connected instance is limited to a small number of changes until one job has completed and stayed. The realiztic failure is an honest one — connecting the instance you did not mean to — and this bounds its cost.
Every customer's data is isolated at the database layer by row-level security, not by application code remembering to filter. A query that forgot its filter returns nothing rather than someone else's records.
Your Acumatica client secret and refresh token are held in Azure Key Vault, separately from the application database, and are read at runtime by managed identity. They are never written to application settings or logs.
Card details are collected by Stripe on Stripe's own pages and never touch our servers. We hold a Stripe customer reference and your subscription status, nothing more. There is no card entry form anywhere in AcuTidy, deliberately.
AcuTidy runs on Microsoft Azure in the United States. Traffic is encrypted in transit with TLS, and data at rest is encrypted by the Azure platform. Connections to your Acumatica instance must use HTTPS; plain HTTP is refused.
Most support work is read-only: whether your connection is working and the real reason if it is not, how your recent jobs turned out, and your billing state. That is enough to answer "why did this fail?" without reading your records.
There are also a small number of actions that change something. Each one records who did it, why, and when, and that record is kept:
What support cannot do is the part that matters most. We cannot read the contents of your Acumatica data: the diagnostic view shows status and outcomes, never your records. And there is deliberately no standing ability for us to change your ERP data outside a job you ran yourself — the only writes AcuTidy makes to your instance are the ones you previewed and confirmed, or an undo of one.
If a case ever needs more than this, we will ask you first and tell you afterwards what was done.
If you believe you have found a security issue, please email support@dlgservicesinc.com. We will acknowledge within five business days and keep you updated. Please give us a reasonable chance to fix it before disclosing it publicly.
AcuTidy has not been through a SOC 2 audit or any equivalent third-party certification, and we do not claim otherwise. If that matters for your procurement process, tell us.