Rivian's SAP purchase-order accrual agent: accounting SOPs as instructions, parked entries and a human approver

In two sentences

Rivian, the US electric vehicle maker, built an agent on Amazon Bedrock AgentCore that prepares month-end accruals for custom tooling purchase orders in SAP S/4HANA: it reads the accounting procedure as plain text, asks PO owners for delivery dates by email, calculates the accrual and leaves a parked entry that a finance manager must approve. Rivian and AWS say it removes more than 15 days of manual work per close cycle, but the account comes from AWS’s own blog, names no model and publishes no volumes, so treat it as a well-documented pattern with self-reported results.

Who does it and why it is interesting

Rivian designs and builds the R1T pickup, the R1S and R2 SUVs and an electric delivery van, with manufacturing in Normal, Illinois, and around 15,000 employees according to the post. Its finance stack runs on SAP S/4HANA hosted in SAP HANA Enterprise Cloud. The case was published on 13 August 2026 on the AWS for SAP blog, written by three AWS architects and co-authored by two Rivian employees: Arunkumar Malli, whose public LinkedIn profile describes him as Senior Manager of ERP Platform Engineering at Rivian, and Sandeep Kodre. SAP has also published a video about the case, and PYMNTS covered it on 11 September 2026.

The commercial interest is obvious: AWS sells Bedrock AgentCore, and the post reads in places like a reference story. We use it anyway for three reasons:

• It is a specific accounting problem, not “AI for finance”. Custom tooling such as stamping dies and injection molds takes 12 to 24 months to develop, and invoices often arrive 18 months or more after the purchase order. Under GAAP, the post explains, the cost has to be recognised gradually over the development period, so someone must track hundreds of open POs, confirm their schedules and book proportional accruals every month.
• The design choices are named. SOPs stored in a knowledge base instead of hard-coded rules, materiality-based routing, an MCP server between the agent and SAP, parked entries and a human approver.
• It is SAP and not Claude-centred. After several cases built on chat assistants, this is an enterprise build on an ERP that many large European groups also run, with a model-agnostic agent framework.

Tools and architecture

The blog lists the components; the way they connect below is our reading of the text, not a diagram Rivian published.

1. SAP S/4HANA holds the purchase orders. The agent detects exceptions “via SAP OData events”, and AWS Lambda functions poll SAP on a schedule.
2. A Strands agent on Amazon Bedrock AgentCore, “powered by a leading LLM model” that the post does not name. Strands is AWS’s open-source agent SDK; AgentCore is the managed runtime, identity and tooling layer.
3. Amazon Bedrock Knowledge Bases store two kinds of documents: the accrual SOPs and SAP API documentation. The agent retrieves the procedure that applies to each PO’s characteristics.
4. An MCP server with custom tools: SAP REST API connectors, email through Amazon SES and case management. The post stresses that any of these (email provider, database, SAP connector) can be swapped without touching the agent’s logic.
5. Amazon DynamoDB keeps the state of each case and a timestamped audit trail that the authors tie to SOX requirements.
6. Security plumbing: AgentCore Identity for the MCP servers, IAM and Cognito for role-based access, Secrets Manager for credentials, CloudWatch for monitoring and AWS CDK for infrastructure as code.

What the agent does on each run, in the order the blog gives: detect exceptions, assemble context from DynamoDB and the knowledge base, decide the route, call tools through MCP to read SAP and send emails, calculate time-proportional accruals with a straight-line method, create parked journal entries for review and manage the approval workflow.

Two details are easy to miss. First, the post says the agent “adapts its approach” to each PO rather than following a fixed path: that is the reason for using an LLM at all, and also the main thing to control. Second, the entries are parked, not posted. In SAP terms a parked document is saved and visible but has no effect on the ledger until someone completes it, which is exactly the place to put a human approval step.

Step by step to replicate the pattern

Rivian’s write-up gives principles, not a runbook. The steps below combine those principles with what any SAP finance team would need; where we add something, we say so.

1. Choose one accrual family with written rules. Rivian started with PO accruals for custom tooling. Good candidates have many open items, long lead times, a formula you can explain and a source of truth for dates.
2. Write the SOP as the agent’s instruction manual. One short document per procedure: scope, data fields, materiality bands, which dates to use, the formula, the account assignment, when to email whom and when to stop. Finance owns it; changing a rule means editing the SOP, not asking for a code change.
3. Load the SOPs and your SAP API notes into a knowledge base so the agent retrieves the right procedure for each PO instead of carrying every rule in one giant prompt.
4. Expose SAP through narrow tools. Read open POs, goods receipts and invoices; write only one thing: a parked entry. Check with your SAP team which interface can do that in your edition. An accepted answer on SAP Community says the standard Journal Entry API in S/4HANA Cloud Public Edition posts directly and cannot park; Rivian’s custom MCP connectors run against a privately hosted S/4HANA, and the blog does not say which API they call.
5. Route by materiality. Small, clean POs can be calculated from the dates on the PO; large or stale ones should trigger a confirmation email to the PO owner and closer review. The bands are yours to set; Rivian does not publish them.
6. Automate the owner follow-up. The agent emails the PO owner, parses the reply and records it. Keep the original email and the parsed dates in the audit trail.
7. Log every step with timestamps: which SOP version was used, what data was read, what the owner said, the calculation and who approved.
8. Run in parallel for at least one close. Compare the agent’s parked entries with your spreadsheet line by line before switching.
9. Keep the approval human and feed corrections back. Rivian’s finance managers approve every entry before posting; when they correct the agent, the fix goes into the SOP.

An SOP excerpt the agent can retrieve (ours, not Rivian’s)

Rivian has not published its SOPs or prompts. This skeleton only turns the principles in the blog into a format you can adapt; amounts, bands and accounts are placeholders.

SOP: Accrual for custom tooling purchase orders — version [N], owner [NAME]

Scope
- Open POs with material group [TOOLING GROUPS], no final invoice,
  development start date filled in.

Data to read (read only)
- PO header and items: amount, currency, vendor, PO owner, start date,
  expected completion date.
- Invoices and goods receipts posted against the PO to date.
- Last month's approved accrual for the PO (from the audit log).

Materiality bands (set your own)
- Below [AMOUNT A]: use PO dates as they are; no email.
- [AMOUNT A] to [AMOUNT B]: email the PO owner if the completion date is in
  the past or more than [N] days old since last confirmation.
- Above [AMOUNT B]: always confirm with the PO owner; flag for senior review.

Calculation
- Months elapsed = whole months from start date to period end (cap at total).
- Cumulative accrual = PO amount × months elapsed / total development months,
  minus amounts already invoiced.
- Entry for the period = cumulative accrual − cumulative accrual already booked.
  The result can be negative (a release) if dates have moved.

Output
- One parked entry per PO in company code [CC], document type [TYPE],
  accounts [DEBIT ACCOUNT] / [CREDIT ACCOUNT], reference = PO number,
  text = "Accrual [PERIOD] SOP v[N]".

Stop and ask a person when
- The owner does not reply by [DATE], or the reply contradicts the PO.
- Invoiced amounts exceed the PO amount, or the currency differs.
- Any field needed for the calculation is missing.

Never
- Never post or complete a parked entry. Never change the PO.

A concrete example (hypothetical numbers)

The source does not give a single PO, amount or entry, so the figures below are invented to show how the pattern behaves.

A stamping die is ordered for $1,200,000, with development planned from January 2026 to June 2027: 18 months, no invoice yet. At the September 2026 close, nine months have elapsed. Following the SOP, the cumulative accrual is 9/18 × 1,200,000 = 600,000.00; 533,333.33 was booked through August, so the agent parks an entry for 66,666.67.

Now suppose the PO is above the confirmation band and the owner replies that the tool will only be finished in September 2027, making the development period 21 months. The cumulative accrual becomes 9/21 × 1,200,000 = 514,285.71, below what has already been booked, so the September entry is a release of 19,047.62. That is the case for asking a person: a spreadsheet using stale PO dates would have over-accrued, and the owner’s email is the evidence an auditor will want to see next to the entry.

Stated results

Everything in this section is stated by Rivian or AWS; none of it is independently measured.

• “Over 15 days of manual work per cycle” eliminated (blog introduction). Yogesh Yadav, Senior Director of Global Finance Systems, adds that they have “eliminated weeks of manual work each month”.
• Five weeks for the proof of concept, after which the solution was fast-tracked to production.
• Audit: “External auditors have praised the transparency” of the agent-driven process compared with the previous spreadsheet calculations.
• Scale: the system is said to absorb the “significant increase” in tooling POs after the R2 launch.
• What is missing: the number of POs, their value (“a large volume”, “significant annual value”), accuracy or error rates, the model used, running costs and any measured change in close length.

PYMNTS headlined the story as cutting “15 Days From Every Close”. Read carefully, the source talks about manual work removed, which is not the same as closing the books 15 calendar days sooner.

Limitations and risks

• Single, interested source. All details come from a vendor blog; PYMNTS, Let’s Data Science and SAP’s video page repeat it. We found no independent technical write-up by Rivian.
• No model, no prompts, no SOPs. You cannot reproduce Rivian’s exact behaviour; you can reproduce the design.
• Judgement is still judgement. Whether a tooling cost should be expensed or capitalised, and over what period, is an accounting policy decision that the SOP must fix in advance. Rivian’s post talks about accruing “expenses” under GAAP; your treatment may differ, and under Spanish or IFRS rules the accounts and policy will too.
• An agent that “adapts” needs limits. The flexibility that justifies an LLM is also what an auditor will question. Narrow tools, a parked-only write path and a complete log are what make it defensible.
• Email as a data source. Owner replies can be vague, late or wrong. The SOP needs a default when nobody answers, and someone must own unresolved cases.
• SAP edition matters. The ability to create parked entries through an API depends on your edition and interfaces; check before you design around it.

Common mistakes

• Putting the rules in the prompt instead of in a versioned SOP. You lose the ability for finance to change them and for auditors to see which version applied.
• Giving the agent a posting user. If it can post, sooner or later it will. Parked entries and a separate approver are the control.
• Skipping materiality. Emailing every PO owner every month trains people to ignore the emails; never emailing them leaves stale dates in the accrual.
• Forgetting that entries can be negative. When dates move, the right answer is often a release, not another accrual.
• Measuring hours instead of quality. Track rejected entries, owner response rates and post-close adjustments, not just time saved.

Conclusions

Rivian’s case is useful less for its headline figure, which nobody outside Rivian and AWS can check, than for its shape: accounting procedures written down as documents the agent retrieves, a thin and swappable tool layer to SAP, a write path that can only create parked entries, and a finance manager who approves every one. That pattern is not tied to AWS or to one model, and it fits any accrual family with clear rules and messy dates. If you try it, start with one family, run it beside the spreadsheet for a close, and let the auditor see the SOP version and the owner’s email next to each entry.