.rpx files are binary-ish XML — technically text, practically unreadable as a diff — and that single fact shapes almost everything about how report development should fit into a version-controlled, multi-developer Acumatica project. I've inherited more than one instance where reports were "in the customization project" but never meaningfully reviewed, because nobody could tell from a git diff what actually changed in a 4,000-line XML blob.
Commit the customization project export, not a loose .rpx
The report file itself lives inside the customization project package once you publish it there, and that package — exported as a .zip, or better, as the unpacked project structure if your build pipeline supports source-controlled customization projects — is what belongs in git, the same as any DAC extension or graph extension in the same project. A loose .rpx file emailed around or dropped in a shared folder outside the project is exactly how two developers end up with silently diverging copies of the same report ID, and the one that gets published last wins with no record of what was lost.
/customization/MyProject/
Reports/
KGSO641P.rpx
KGSO641P.xml (metadata: description, screen ID mapping)
DAC/
Graphs/
project.xml (manifest listing everything in the package)You cannot meaningfully code-review an .rpx diff — plan around that, don't fight it
Git will show you the XML delta on an .rpx change, and it will be technically accurate and practically useless for a human reviewer — attribute reordering and internal ID churn drown out the one layout change that actually matters. The workable process is not "review the diff," it's "review a rendered before/after." Export a PDF of the report with representative test data before the change and after, and attach both to the pull request or ticket. That's the actual code review artifact for a report change — the XML diff is there for the record, not for a human to read.
Because the XML diff is unreadable, I put a small changelog directly in the report — either as a comment-style hidden label on the design canvas, or in the report's Description field on the Report Designer's properties — noting date, author initials, and a one-line summary of what changed. It's low-tech, but it's the only changelog anyone will actually read six months later when trying to figure out why a subtotal moved.
Two developers, one .rpx: lock it, don't merge it
Unlike C# files, there is no realistic three-way merge for a binary-structured report two people edited concurrently — whoever saves last overwrites the other's layout changes with no warning. If more than one developer might touch the same report in a sprint, treat it like a design asset, not code: claim it explicitly (a Slack message, a ticket assignment, a file lock convention) before opening it in the designer, and merge by hand — reapplying the smaller change on top of the larger one — rather than trusting git to reconcile two divergent binary-ish exports.
Wrapping up
Version-control the customization project package, not loose report files passed around outside it. Accept that the XML diff isn't reviewable and replace code review with a rendered before/after PDF comparison, keep a manual changelog inside the report since git's own history won't be legible later, and coordinate concurrent edits explicitly since there's no real merge story for a report two people changed at once.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.