# AI for Dynamics SL, grounded on your project and contract data

> Source: https://netray.co/erp-ai/dynamics-sl-ai-integration
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## Short answer

Dynamics SL still runs project accounting and DCAA-compliant timesheets for a lot of government contractors who have no plan to move off it soon. A private LLM grounded read-only on SL's SQL Server database can answer project, contract, and indirect rate questions in plain language, and can run entirely on infrastructure a CIO controls, without sending CUI or contract cost data to a public AI API.

## Kind

platform

## Erp Family

microsoft

## Erp Products

- Microsoft Dynamics SL
- Dynamics SL 2018
- Solomon IV (legacy)

## Industries

- Government Contracting
- Aerospace
- Defense
- Professional Services

## Region

United States

## Persona

CIO

## Eyebrow

Dynamics SL + on-prem AI

## Intro

Dynamics SL is a project and contract accounting system built for exactly the kind of organization Microsoft has mostly stopped talking about: government contractors, professional services firms, and aerospace and defense subcontractors who need DCAA-compliant timesheets, indirect rate pools, and funded-value tracking down to the task order line. Microsoft's newer investment goes to Business Central and Dynamics 365 Project Operations, but a large population of SL customers have no near-term reason to move, because the system does exactly the specific job it was built for.

The problem is not that SL fails at its job. It is that nobody outside the controller's office and a couple of finance staff can get a straight answer out of it without a report request or a spreadsheet pull. A program manager asking what is left on a task order's funding ceiling, or an indirect rate group asking why the provisional overhead rate moved this period, waits on the same two or three people every time, and those people are also the ones preparing the annual incurred cost submission.

That is a grounding problem, not a system-replacement problem. SL's project and contract data lives in an ordinary SQL Server database, reachable read-only, and an AI layer built on a proper semantic mapping of its Project Controller, Contract, and Timesheet tables can answer the recurring questions directly, cite the source records, and leave the actual DCAA labor-charging controls and approval workflows exactly as they are.

For a CIO evaluating this, the constraint that matters most is data handling. Dynamics SL customers who are DCAA-audited or CMMC-scoped cannot casually route contract cost and labor data through a shared public AI service. The architecture that fits is the same one that fits any regulated ERP: read-only connection to SL's database, a model that runs on hardware the company controls, and a design that never writes back to a labor or billing record without a person approving it first.

## Pain Points

### DCAA audit prep is a manual scramble every year

**Detail:** Building the incurred cost submission means pulling project ledger detail and mapping it to ICE schedules by hand, usually under deadline pressure and usually by the same one or two people.

### Indirect rate variance takes a spreadsheet rebuild every close

**Detail:** Explaining why the provisional overhead or G&A rate moved this period means recreating the rate pool calculation manually, since SL does not narrate the variance for you.

### Funded value and burn-rate risk surfaces late

**Detail:** A task order approaching its funding ceiling is often discovered when billing is about to exceed it, not weeks earlier when a program manager could still act.

### Legacy VB.NET customizations are undocumented

**Detail:** Custom screens built with the Dynamics SL SDK years ago run the business today, but the people who wrote them have often moved on, leaving no real documentation.

### Microsoft's own AI roadmap has bypassed SL

**Detail:** Copilot and generative AI investment goes to Business Central and Project Operations; SL customers get no native path to the same capability inside the product.

## Use Cases

### Plain-English project and contract status

**Description:** A program manager asks what has been billed against a contract, what remains on a funded task order, or where a project stands against budget, answered from live Project Controller and Contract module data.

**Erp Objects:** Project Controller (project ledger, budget), Contract module (funded value, billed value, ceiling)

**Outcome:** Cuts routine status questions from a request to the PM office down to a self-service question with the source records cited.

### DCAA timesheet exception review

**Description:** An agent reviews recent Timesheet Entry and labor distribution activity for missing entries, late submissions, and unusual charging patterns ahead of a compliance review, rather than waiting for an audit sample to find them.

**Erp Objects:** Timesheet Entry, Labor Distribution, employee/project charge codes

**Outcome:** Surfaces labor-charging exceptions before an auditor does, without changing SL's own timesheet approval workflow.

### Indirect rate variance explanation

**Description:** A controller asks why the provisional overhead or G&A rate changed this period and gets a plain-language walk-through of the pool and base changes driving it, grounded in the actual rate pool tables.

**Erp Objects:** Overhead/G&A cost pools, provisional billing rate tables, GL account groupings

**Outcome:** Turns a spreadsheet rebuild into a grounded explanation delivered in minutes, with every figure traceable to a GL account.

### Incurred cost submission prep assistant

**Description:** Pulls project ledger detail and maps it to the relevant ICE schedule categories, giving the accounting team a structured starting draft instead of a blank spreadsheet each year.

**Erp Objects:** Project ledger detail, GL account mapping, indirect cost pool structure

**Outcome:** Shortens the annual ICE/incurred cost submission prep cycle, with the underlying transactions cited for the audit trail.

### Funding ceiling and burn-rate early warning

**Description:** A scheduled agent compares billed and committed cost against each task order's funded value and flags orders trending toward their ceiling before it becomes a stop-work risk.

**Erp Objects:** Contract module funded/billed/ceiling values, Project budget

**Outcome:** Gives program managers weeks of lead time instead of discovering a ceiling breach at invoice time.

### AP document intake and PO matching

**Description:** OCR and classify vendor invoices, then propose a match against open purchase order lines in SL for a clerk to confirm before it posts.

**Erp Objects:** Accounts Payable module, purchase order detail

**Outcome:** Cuts manual keying and matching time on routine vendor invoices while leaving posting to a person.

### Legacy customization documentation assistant

**Description:** Point a code-aware model at exported Dynamics SL SDK screens and VB.NET customizations to generate plain-English descriptions of what each one does, ahead of any future migration decision.

**Erp Objects:** SL SDK custom screens, VB.NET/COM customization source

**Outcome:** Builds a documentation baseline in weeks instead of depending on the one person who remembers why a screen was built that way.

## Architecture

**Overview:** A read-only layer on Dynamics SL's SQL Server database, grounded on Project Controller, Contract, and Timesheet data through a purpose-built semantic mapping, with model serving kept off any public AI API for CUI and contract-cost sensitivity.

**Layers:**

#### SL connectivity

**Detail:** Direct SQL Server read replica or a scoped, read-only database login against the SL database; the Dynamics SL SDK is used only where a specific, approved write-back is later required.

#### Semantic layer

**Detail:** A mapping from SL's project, contract, and timesheet table and field names to the vocabulary a program manager or controller actually uses, built with input from whoever runs project accounting today.

#### Model serving

**Detail:** Open-weight models served on infrastructure the company controls, sized to the organization's query volume, with no contract cost or labor data sent to a shared public AI service.

#### Retrieval and agents

**Detail:** Text-to-SQL for structured project, contract, and rate questions; scheduled exception agents for timesheet review and funding ceiling monitoring; document RAG for AP and contract file intake.

#### Governance and audit

**Detail:** Every answer logged with the specific project, contract, or GL records it drew from, so a controller or DCAA auditor can trace an AI answer back to source transactions.

## Deployment Options

### Air-gapped on-prem

**Fit:** Defense subcontractors and CMMC-scoped GovCon firms who cannot let CUI or contract cost data touch a network path outside their control.

**Detail:** Model, semantic layer, and SL read replica all run on company-owned hardware with no outbound path for inference traffic.

### Private or sovereign cloud

**Fit:** Contractors comfortable with cloud economics but not with a shared public AI API touching labor and contract cost data.

**Detail:** Dedicated-tenant deployment connecting to SL over a controlled, logged connection, with data residency matched to existing compliance obligations.

### Hybrid

**Fit:** Organizations wanting to prove one use case, such as funding ceiling monitoring, before committing budget to a wider rollout.

**Detail:** A scoped pilot on modest hardware, same read-only architecture, extended once the use case has proven its value.

## Compliance

### The AI layer reads timesheet and labor distribution data to surface exceptions; it does not alter labor charging, approval routing, or any control DCAA already audits.

**Framework:** DCAA compliance

### Where SL data touches CUI, model serving and the semantic layer stay on infrastructure inside the same enclave, with no data sent to a public AI API.

**Framework:** CMMC / DFARS 252.204-7012 / NIST SP 800-171

### For defense-adjacent contractors, technical and contract data stays on company-controlled hardware, with access scoped to authorized US persons where required.

**Framework:** ITAR / export control

### Rate variance and incurred cost explanations are read-only aids to the controller; the actual journal entries and rate calculations remain SL's system of record, unaltered by the AI layer.

**Framework:** GAAP and internal financial controls

## Integration Notes

Use a scoped, read-only SQL Server login against the SL database, or a nightly/near-real-time replica, rather than granting broad access through the SL SDK.

Build the semantic layer with the controller or whoever currently owns indirect rate calculations; SL's project and contract table structure is coherent but not self-explanatory to an LLM without that mapping.

Keep write-back out of scope for the initial rollout; if it is added later (for example, drafting a timesheet correction for review), route it through the SL SDK's standard APIs with explicit human approval.

Confirm how provisional billing rates and rate pool structures are configured for the specific contracts in scope; rate methodology varies enough between GovCon shops that this cannot be assumed generic.

If SL customizations built with the SDK are heavily used, export their source for the documentation use case separately from the live database connection, so the model never needs write or execute access to custom code.

Size funding ceiling monitoring to check against committed cost, not just billed cost, since committed-but-unbilled cost is usually the earlier warning signal a program manager needs.

Log every generated query and every answer with the source table and record identifiers, since this is exactly the kind of evidence a DCAA or CMMC assessor will want to see if the AI layer is ever in scope for review.

## Product Fit

### Custom build

**Why:** DCAA timesheet exception logic, incurred cost submission mapping, and funding ceiling monitoring are specific enough to GovCon project accounting that they are typically built as a custom layer on top of SL's data.

### ERPray

**Why:** Once the SL semantic layer exists, ERPray's connector pattern can provide general-purpose, cited question-answering over project and contract data for program managers and finance staff.

## Engagement

### Discovery

**Duration:** 2-3 weeks

**Deliverables:**

- Project, Contract, and Timesheet table mapping to business vocabulary
- Confirmed read-only connectivity approach
- Security review with IT and the controller's office
- Prioritized use case and success criteria

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- Working semantic layer for the pilot data domain
- Model serving stood up on company-controlled infrastructure
- 5-10 real project or contract questions answered end to end with cited sources
- Pilot review with CIO and controller

### Production

**Duration:** 8-10 weeks

**Deliverables:**

- Hardened replica or connection with defined refresh cadence
- Role-based access aligned to existing SL security
- Audit logging suitable for DCAA or CMMC review
- Runbook for IT to operate and maintain the connector

### Scale

**Duration:** ongoing

**Deliverables:**

- Additional domains (AP intake, rate variance) added to the semantic layer
- Funding ceiling monitoring extended across all active contracts
- Quarterly review of query patterns and audit-readiness

## Buyer Questions

- Does your approach require any change to SL's timesheet or labor-charging controls, or is it strictly read-only?
- Where does the model run relative to our network, and can you guarantee no contract cost or CUI data reaches a public AI API?
- How do you build the mapping between SL's project and contract tables and our actual DCAA rate methodology?
- Who builds and maintains the semantic layer, and how much of our controller's time does that require?
- Can you show a real example of the SQL your system generated against Project Controller or Contract module data?
- How does this hold up under a CMMC or DCAA audit; what evidence trail does the AI layer produce?
- What happens to this project if we later migrate off Dynamics SL?
- What is your rollback plan if the read replica falls behind during a close or an audit period?

## Faq

### Can AI answer project and contract questions directly from Dynamics SL?

**Answer:** Yes. SL's project, contract, and timesheet data lives in an ordinary SQL Server database, reachable read-only. Once a semantic layer maps that data to plain business terms, an AI layer can answer status, funding, and rate questions with the source records cited, without changing anything in SL itself.

### Does this change or automate DCAA labor charging?

**Answer:** No. The standard design is read-only: it reviews timesheet and labor distribution data to flag exceptions for a person to review, and it does not alter labor charging, approval routing, or any control DCAA already audits.

### Is our contract cost and CUI data safe from a public AI API?

**Answer:** It can be kept entirely off one. Model serving, the semantic layer, and the SL read connection can all run on infrastructure your organization controls, which is the standard architecture for CMMC-scoped or ITAR-relevant contractors.

### Can this help with the annual incurred cost submission?

**Answer:** Yes. An agent can pull project ledger detail and map it to the relevant ICE schedule categories, giving accounting a structured draft with every figure traceable to source transactions, rather than starting from a blank spreadsheet.

### Will this catch a task order approaching its funding ceiling?

**Answer:** A scheduled monitoring agent can compare committed and billed cost against each task order's funded value and flag orders trending toward their ceiling well before billing would exceed it, giving program managers time to act.

### What about our old SL SDK customizations nobody documented?

**Answer:** A code-aware model can read exported VB.NET and SDK customization source and generate plain-English descriptions of what each screen does, useful as a documentation baseline for onboarding staff or scoping a future migration, without executing or modifying the code.

### Does this require us to plan a migration off Dynamics SL?

**Answer:** No. The architecture is designed to add value to the system you are running today. It also happens to produce useful documentation and usage data if a migration decision comes up later, but that is not a prerequisite.

## Search terms

Dynamics SL AI, Dynamics SL AI integration, AI for Dynamics SL, on-prem AI for Dynamics SL, Dynamics SL DCAA AI, Dynamics SL copilot, Dynamics SL generative AI, GovCon ERP AI, Dynamics SL project accounting AI, Dynamics SL indirect rate AI, Solomon IV AI integration, DCAA compliant AI ERP, Dynamics SL incurred cost AI, government contractor ERP AI

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json