Microsoft DynamicsERP PlatformUnited States

Dynamics SL + on-prem AI

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

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.

ERP
Microsoft Dynamics SL, Dynamics SL 2018, Solomon IV (legacy)
Industries
Government Contracting, Aerospace, Defense, Professional Services
Written for
CIO

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.

What usually gets in the way

The problems we hear most from cio teams running Microsoft Dynamics SL.

DCAA audit prep is a manual scramble every year

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

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

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

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

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.

Where AI earns its place in Microsoft Dynamics SL

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Plain-English project and contract status

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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

Touches: 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

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.

Touches: 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.

Reference architecture

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.

  1. 1

    SL connectivity

    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.

  2. 2

    Semantic layer

    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.

  3. 3

    Model serving

    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.

  4. 4

    Retrieval and agents

    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.

  5. 5

    Governance and audit

    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.

Integration notes for your ERP team

  • 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.

Deployment options

Air-gapped on-prem

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

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

Private or sovereign cloud

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

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

Hybrid

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

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

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

DCAA 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.

CMMC / DFARS 252.204-7012 / NIST SP 800-171

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.

ITAR / export control

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

GAAP and internal financial controls

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.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

  • -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

Phase 2 . 6-8 weeks

Pilot

  • -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

Phase 3 . 8-10 weeks

Production

  • -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

Phase 4 . ongoing

Scale

  • -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

Questions to ask any vendor, including us

A short list that separates real Microsoft Dynamics SL AI work from a chatbot demo.

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

Frequently asked questions

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

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?

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?

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?

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?

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?

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?

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.

Talk it through with an engineer who knows Microsoft Dynamics SL

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.