Commons Project: DLRS

Hi Monty, 

This is a known DLRS behavior with multi-currency orgs, not a config mistake on your end. Since your rollup uses an aggregate SOQL query (SUM) under the hood, Salesforce's database engine automatically converts all child records' currency into the org's corporate currency before summing — even for records that already match the target field's currency — and this conversion step introduces rounding/precision loss. That's exactly why your rolled-up value comes out slightly lower than the actual OLI value, even with just one line item. 

This is documented as a longstanding, open issue in the DLRS project itself (not something recent or specific to your setup) — it happens whenever the record's currency isn't the org's native/corporate currency, since the aggregate query silently converts before summing. 

Practical options: 

1. Check your org's dated exchange rates — if you're on Advanced Currency Management, small discrepancies often trace back to which exchange rate date DLRS's underlying query picks up versus what you expect. 

2. If exact precision matters, consider switching this specific rollup to Rollup Helper (Passage Technology) instead — it explicitly markets better handling of currency-field rollups in multi-currency orgs, and even provides a one-click converter for existing DLRS rules. 

3. As a workaround, you could roll up a plain Number field (not Currency type) representing the OLI amount in a fixed reference currency, sidestepping the currency-conversion-before-sum behavior entirely. 

Reference:

Worth checking if the gap matches your org's current corporate-currency exchange rate — that'll confirm this is exactly what's happening rather than something else.

Invocable by Automation means taking control of timing and change detection. Best used with Flows or Scheduled Recalculation. Invocable by Automation disables all the "proactive" parts of DLRS for that rollup. Something else has to tell is that it is time to recalculate. 

People will often drive DLRS via Flow when they need advanced criteria to know when a record should force an update, or because they want to use an async path to cause the rollup to update. (usually faster than Watch for Changes) 

Scheduled Recalculation isn't really a "mode" by itself. It is the bulk reconciliation process. Paired with Invocable by Automation means DLRS only recalculates when told and that recalculation is across the entire dataset, not focussed on only those records that need to change. You can also use this with other modes, such as Realtime. If my Relationship Criteria uses a related object or relative dates (such as THIS_MONTH) then I need a Scheduled Recalculation as a backup to run once in a while and make sure all the values are correct. Realtime and Scheduled can only evaluate records when they are saved, if the change is isolated to the formula logic, or driven by a related record, then DLRS doesn't notice. 

Realtime is usually best for when a rollup value MUST always be correct. If that field ever didn't match the data in the system it could mean real harm for your business. For most people this isn't the case but it still gets used often because people think they want it. As you've already figured out, Realtime is the most likely to expose errors because it adds the most processing work during the original record save so if it has problem or encounters something like a validation rule then DLRS will prevent the child from saving. 

Scheduled/Watch for Changes is great for focussed updates that don't need to be immediate. It doesn't need to process every record in the system but can still delay processing for the RollupJob. This helps to separate the work that needs to be done from the act of saving child records. For most people this is good enough. It gives fewer errors to end-users and updates the rollup value when it is convenient. I usually recommend running every hour but I know many people need every 15 minutes. It is about how long you can go without the number being correct. Because errors are moved to a background job it becomes important to monitor the DLRS Log object, that is where most problems from here or the Scheduled Recalculate will show up. 

Hopefully that adds more detail and decision points. There are a lot of ways to reach your goal. Usually I would recommend using Watch for Changes unless you have a reason to do something else.

@Zarina Varley Scott

I'm not aware of any specific problems here. Can you give me any additional insight into how you have this user setup? Have you assigned any of the packaged Permission Sets to this Integration User? 

I don't have a setup like this right now but maybe I can try and replicate it and test it when I have some time. 

Normally if the Schedule Item record can't be written it will cause a failure during the transaction. It sounds like your records are correctly saving though. Is it possible your Integration User doesn't have access to the Custom Metadata records so it doesn't know about the configured rollups? I'd try assigning the built-in Permission Sets and see if that makes a difference.

Install the same DLRS package version in production first. Then deploy the rollup’s Custom Metadata record through a change set or your usual metadata deployment process.

If the rollup uses Realtime or Watch for Changes and Process Later mode, include the DLRS-generated trigger and test class as well. Any scheduled jobs will need to be recreated manually in production. Once deployed, run a recalculation and test the rollup with a sample record before activating it fully.