Verified ERP Reporting
Spec-driven Generic Inquiry, report, and dashboard builds for Acumatica and
JAMIS Prime – every artifact ships with a machine-verification evidence packet.
Written June 2026.
The offer in one sentence – We build your Generic Inquiries, Report
Designer reports, and dashboards from a
written spec, validate them offline before anything reaches your site.
The problem this solves
Anyone can edit an Acumatica or JAMIS Prime report. Almost nobody can prove
the edit is the intended one, that nothing adjacent changed, and that it is
safe to promote – which is exactly what a reviewer in a FedRAMP, CMMC, or
SOX-adjacent environment needs before a report ships. The standard deliverable
in this market is a changed file and a verbal assurance. Ours is a changed
file and the evidence.
(The full argument for why “I tested it” fails change-control review is in our
companion guide: Verified ERP Reporting – Proving a Report Change Is Correct
Before It Ships.)
What we build
- Generic Inquiries (GIs) – built from a spec, with every DAC and field
reference checked against the catalog before delivery. - Report Designer reports (
.rpx) – new builds and proven-safe edits to
existing reports (logo, field, label, formula, section, parameter changes). - Dashboards – packaged for import.
- Reporting diagnostics – when an existing report misbehaves, a mechanical
diff against a preserved vanilla baseline answers “what actually changed?”
with evidence instead of archaeology.
What makes the builds different
1. Validated before it reaches you. Every build is checked offline
against the structure of the exact platform version you run. A GI that names
a field that doesn’t exist, or a report that drifts from the platform’s own
structural conventions, fails validation on our side – not on your site. Any
edit we cannot prove safe, we refuse to ship.
2. Every artifact ships with a machine-verification packet. A JSON +
Markdown evidence packet, filed with the change, recording:
- a parse check – every expected artifact exists and is well-formed XML,
with a SHA-256 hash identifying the exact bytes verified; - a vanilla-vs-working diff – the change is real (provably differs from a
preserved baseline) and bounded (baseline and pre-change backup present); - a side-effect attestation – the work performed no ERP access, no
publish, no email, no repository writes; any recorded external action is a
hard verification failure; - a human-gated readiness status – the engine structurally cannot declare
anything production-ready; promotion is always a person’s signature.
3. Honest refusals. The verification engine does not execute reports
against your data and does not assert that the total on page three is the
right number. The render/regression check – opening the artifact on the
target version and confirming it behaves – is a human validation step that
the packet gates, queues, and records. A verification layer that overclaimed
would teach reviewers to rubber-stamp; the scope limits are the feature.
How an engagement runs
- Spec – we write down what the artifact must do (entities, fields,
filters, grouping, parameters, output) and you approve it. Unstated
assumptions are where report projects fail; the spec is the contract. - Build + offline validation – the artifact is generated and validated
against the catalogs and structural rules before you ever see it. - Machine verification – the evidence packet is produced: parse, diff,
side-effect screen, readiness gate. - Human render/regression pass – on your test instance, on the record,
gated by the packet. - Promotion – explicitly approved by a person. If your site is SSO-only,
the publish path itself is a solved problem – see
Report Designer on SSO-Only Sites.
What’s proven and what’s pending (as of June 2026)
- Proven: the verification engine is versioned (0.1), spec-driven, and has
been used on live report-build engagement work – the packets described above
are its actual output, on report artifacts. The deterministic builders and
validators run on every build. - Stated as an extension, not equal mileage: GIs and other XML-exportable
definitions are the same kind of artifact and get the same checks; the
engine’s track record is on report artifacts. - Pending, and never claimed otherwise: the live publish round-trip has
been validated against a vanilla, native-auth sandbox – not against your
site, which is the point: promotion to your environment is a gated,
per-engagement step, never an assumed one.
Who this is for
Acumatica and JAMIS Prime sites where report changes pass through real change
control – FedRAMP, CMMC, SOX-adjacent, or simply a serious internal IT policy –
and teams that have been burned by an upgrade or a customization publish
silently altering a report nobody had baselined.
Next step
Book a consultation
or email [email protected]
– bring the report or GI you need built or fixed, and we’ll scope it as a
fixed, spec-driven build with the evidence packet included.
Contact
A reporting-layer diagnostic or a verified report build – every shipped change comes with its evidence packet.
Or email [email protected].