Coding models can produce convincing Acumatica C#. They can also reference fields that do not exist, attach logic to the wrong event or reproduce standard behaviour in a custom path that later falls out of step with the platform.
In his ERP SEAL Podcast conversation, AISI Technical Lead Aleks Iwan described seeing models confidently invent Acumatica fields. The code may look reasonable to somebody familiar with C# while failing a basic platform check.
AI assisted development therefore needs an acceptance path built around Acumatica behaviour. The model can help implement the change. The requirements, platform fit and evidence determine whether the change is ready.
Define the business result before generating code
Acceptance begins with the process the customisation must support.
For a Sales Order screen change, the requirement should explain more than the fields or tabs to add. It should identify:
- which users encounter the change
- how records are classified
- which fields become available or required
- what happens when the classification changes
- which standard actions must continue to work, and whether their behaviour is expected to change
- which permissions apply
- what should happen when data is incomplete
That description gives the implementation and its tests the same target. Without it, a model can produce a polished screen that quietly breaks allocation, pricing, shipment creation or invoicing later in the order lifecycle.
The same principle applies to a financial subledger, integration screen or custom approval. Start with the document states, accounting effects, user decisions and failure paths. A list of controls is rarely enough to describe the job.
Review the Acumatica extension point
A model may solve the visible symptom through a technically available route. The first review should establish whether that route fits Acumatica.
Check the proposed use of:
- DAC and DAC extension fields
- graph and graph extension logic
- field, row and persist events
- actions and workflow states
- BQL queries and selectors
- custom endpoints and contract extensions
- long operations and processing screens
The question is whether the change participates in standard platform behaviour rather than building a parallel version of it.
For example, filtered tabs on a Sales Order should normally remain views of the underlying order lines. Creating a second store for those lines may make the custom tab easier to generate while introducing synchronisation and downstream processing problems.
This review requires Acumatica knowledge. General C# quality can reveal an unsafe query or poor structure. It cannot tell the reviewer that the wrong graph owns the business action or that a standard event already provides the required behaviour.
Treat compilation as the first gate
Compiling the extension confirms that its compile-time references resolve against the target build. Runtime behaviour remains open. The event may run at the wrong time, the query may return unintended records or the customisation may interrupt standard processing.
A practical sequence can include:
- Compile against the target Acumatica version.
- Publish into a clean test instance with representative features enabled.
- Exercise the custom screen or action with controlled data.
- Run the full business process affected by the change.
- Repeat the important paths with different roles and failure conditions.
- Check the next Acumatica release or supported target builds where upgrade compatibility matters.
The clean instance matters. A development site may contain unpublished assumptions, old customisations or data that makes the new code appear complete.
Match each check to the behaviour
Acumatica provides more than one testing surface because different failures need different evidence.
Unit tests are useful for isolated business logic. They can cover calculations, classification, validation and transformations without navigating the full UI.
The Acumatica Test SDK can exercise user paths through screens. It is useful when the requirement depends on field visibility, actions, navigation or the sequence in which a user works through a document. Acumatica has also used Test SDK coverage in application certification to run primary use cases across releases.
A complete scenario test follows the document beyond the custom screen. A Sales Order customisation may need to preserve:
- pricing and discount calculation
- tax behaviour
- inventory allocation
- purchase links
- shipment creation
- invoice creation
- totals and status transitions
The correct list comes from the requirement. Running every available test does not compensate for missing the process that actually carries the risk.
Sources: Acumatica’s guidance on Test SDK tests and testing customisations through delivery pipelines.
Keep test design independent from the generated answer
A coding model can generate useful test cases. It can also encode the same misunderstanding in both the implementation and the tests.
Derive core acceptance cases from the business requirement, known platform behaviour and real failure history. Use generated cases to widen coverage after the essential paths are fixed.
Good cases include both action and restraint:
- the field appears when the qualifying condition is true
- the field remains hidden when the condition is false
- a valid document proceeds
- an invalid document stops with a useful message
- an authorised role can use the action
- another role cannot
- the custom logic runs once when the record is retried
- an upgrade keeps the expected behaviour
This reduces the chance that implementation and test agree with each other while disagreeing with the job.
Use platform expertise where it changes acceptance
Anthropic’s analysis of roughly 400,000 coding sessions found that domain expertise improved success and recovery. People tended to make planning decisions while the coding agent handled more execution decisions.
That division fits Acumatica development. A model can search, implement, refactor, explain and generate test data. The Acumatica specialist decides what the system should do, recognises an invented field, chooses the platform boundary and reads a failure in business terms.
The specialist may let the model write most of the lines while retaining authority to reject code that is syntactically convincing and operationally wrong.
Keep the requirement, target Acumatica build, test data, expected states and release result beside the customisation. When a later model or developer changes the same area, those artifacts provide a faster route to the original reasoning.
Failed cases are valuable too. A regression test created from a production fault prevents the next plausible implementation from reopening it.
AI can shorten the distance between a requirement and working code. Acceptance remains a separate piece of engineering, shaped by Acumatica and the process the customisation is meant to carry.