Intelligent Document Processing at Scale with AI-Powered Tax Compliance and Invoice Analysis

syngenta · Other · 2025 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise invoice and policy-compliance document processing

Syngenta needed to extract richer content from invoices and related documents at global scale, then compare that content against tax, vendor, procurement, and expense policies. Legacy OCR and basic ML supported only enough invoice fields for SAP three-way match, while tax compliance in Argentina still required manual checking of thousands of invoices against complex state- and product-specific tax policies.

Constraints:

• most enterprise data is unstructured and difficult to feed into downstream business processes
• Syngenta operates globally across 90 countries with over 30,000 employees
• the company processes about one million invoices and roughly two and a half million invoice-related documents per year
• legacy OCR/basic ML extracted only enough data for three-way match in SAP
• Argentina tax law varies by state and by what was purchased
• tax users needed explanations, not just flags
• invoice data had to be compared with SAP postings, tax policy, vendor master data, and expense policy
• the architecture needed to remain modular for model experiments, BDA tuning, and new use cases

Architecture

Syngenta built Wingman, an intelligent document processing pipeline around SAP, S3, Redshift, Glue, Amazon Bedrock Data Automation, Amazon Bedrock, Claude, OpenSearch Serverless, and Power BI. SAP ERP runs on EC2; invoice and business data are extracted into Redshift and documents are archived in S3. Glue jobs feed posted SAP data into OpenSearch. PDFs flow into Bedrock Data Automation, which performs OCR plus LLM-based linearization into structured JSON. The structured document output and policy context are sent to Amazon Bedrock, primarily Claude, to compare invoice details against tax policy and generate suggestions and explanations. Results are stored in OpenSearch and shown in Power BI dashboards alongside SAP postings.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  SAP_ERP_on_EC2["SAP ERP on EC2"] --> Redshift_analytics_lake["Redshift analytics lake"]
  SAP_ERP_on_EC2 --> S3_document_archive["S3 document archive"]
  Redshift_analytics_lake --> Glue_ETL_jobs["Glue ETL jobs"]
  Glue_ETL_jobs --> OpenSearch_Serverless["OpenSearch Serverless"]
  S3_document_archive --> Amazon_Bedrock_Data_Automation["Amazon Bedrock Data Automation"]
  Amazon_Bedrock_Data_Automation --> Document_JSON_output["Document JSON output"]
  Document_JSON_output --> Amazon_Bedrock_comparison_layer["Amazon Bedrock comparison layer"]
  Tax_policy_context["Tax policy context"] --> Amazon_Bedrock_comparison_layer
  Amazon_Bedrock_comparison_layer --> Model_experimentation_loop["Model experimentation loop"]
  Amazon_Bedrock_comparison_layer --> Wingman_suggestion_records["Wingman suggestion records"]
  Wingman_suggestion_records --> OpenSearch_Serverless
  OpenSearch_Serverless --> Power_BI_Wingman_dashboard["Power BI Wingman dashboard"]
  Power_BI_Wingman_dashboard --> Tax_and_legal_reviewers["Tax and legal reviewers"]
  Tax_and_legal_reviewers --> Tax_policy_update_workflow["Tax policy update workflow"]
  Tax_policy_update_workflow --> Tax_policy_context
  AP_chatbot_workflow["AP chatbot workflow"] --> Amazon_Bedrock_comparison_layer

Components

Data flow

Invoices and related SAP documents are archived from SAP into S3, while SAP tables are extracted into a Redshift analytics lake. Glue ETL sends SAP-posted data to OpenSearch Serverless. Invoice PDFs are processed by Amazon Bedrock Data Automation into structured JSON/linearized document output. That output, plus tax-policy context compiled by Syngenta, is sent to Amazon Bedrock using Anthropic Claude to determine suggested tax classifications, mismatches, explanations, and other document insights. OpenSearch stores both SAP data and Wingman suggestions, and Power BI dashboards show SAP values, AI suggestions, match/mismatch indicators, invoice details, confidence scores, and explanations.

Why this architecture

Syngenta chose a modular document-lake and LLM-comparison architecture because the same invoice content can support multiple business problems once it is extracted richly enough. BDA handles the document-to-JSON step, Bedrock/Claude performs policy comparison and explanation, OpenSearch/Power BI make the output auditable, and modularity lets the team swap models, tune BDA outputs, use prompt caching, and adapt Wingman to procurement, vendor master, expense, and tax use cases.

Models used: Amazon Bedrock Data Automation · Anthropic Claude · Amazon Nova models evaluated · OCR plus LLM techniques · in-house LLM for other Syngenta internal processes

Scale

• The presentation says 80% of company data is mostly unstructured.
  “80% of the data we have in our companies are mostly unstructured.”transcript, stated
• Less than 20% of companies have processes in place for unstructured data at scale, according to the presentation.
  “this is where less than 20% of companies have processes in place”transcript, stated
• Syngenta operates in 90 countries.
  “we're global operating in 90 different countries. So um very big spread.”transcript, stated
• Syngenta has more than 30,000 employees.
  “there's lots of us 30,000 people more work for Senta. And it's very very much a science-based company as well.”transcript, stated
• Syngenta processes about one million invoices yearly.
  “As in Genta, we process a million invoices every year. Um, with with more documents associated with invoices”transcript, stated
• Invoice-related documents total about two and a half million per year.
  “more documents associated with invoices that two and a half million a year, credit notes, all sorts of things.”transcript, stated
• The Argentina tax use case involves roughly 4,000 invoices per month.
  “we don't have that many use invoices to process in Argentina 4,000 a year, but tax law in Argentina is kind of 4,000 a month.”transcript, stated

Alternatives considered (roads not taken)

Legacy OCR/basic ML invoice extraction

Rejected because: The existing pipeline extracted only enough information for SAP three-way match and could not unlock richer invoice-content use cases.

Manual tax-policy checking

Rejected because: Manual invoice comparison against Argentina tax policy was boring, time-consuming, and error-prone.

Inline expense compliance only

Rejected because: Syngenta was still debating whether inline Concur checks or periodic batch audits were the right operating model for expenses.

One fixed model and prompt strategy

Rejected because: The team experimented with Nova, Anthropic models, and prompt caching to optimize cost per page, accuracy, and performance.

Patterns

batch-offline-processing (operations)

Wingman processes invoice PDFs and SAP extracts through ETL, BDA, Bedrock, OpenSearch, and Power BI, with both batch invoice processing and future AP batch checks.

structured-output-contract (interface)

BDA turns documents into structured JSON/linearized output, and Wingman records structured suggestions that can be displayed next to SAP data.

rag-retrieval (retrieval)

The system passes structured invoice content plus tax-policy context into Bedrock so the model can compare document facts against policy.

model-routing (modeling)

Syngenta used Bedrock's model choice to experiment with Nova, Anthropic models, and prompt caching for cost and accuracy tradeoffs.

human-in-the-loop-gate (workflow)

Tax and legal users review Wingman dashboards, and future tax-policy changes proposed by Wingman require human validation before policy updates.

eval-driven-development (quality)

The architecture exposes confidence scores, grounding, match/mismatch indicators, and dashboard drilldowns so users can inspect model suggestions.

cost-aware-routing (operations)

Prompt caching and model experiments were used to reduce page-level cost while improving accuracy and performance.

Tradeoffs

Use a modular AWS architecture.

Chose BDA, Bedrock, OpenSearch, Glue, Redshift, S3, and Power BI as swappable modules over a monolithic invoice-processing system.

Rationale: Modularity lets the team tune BDA outputs, switch models, experiment with prompt caching, and extend Wingman to more use cases.

Process invoices through LLMs for richer business insight.

Chose LLM-driven invoice content understanding over extracting only SAP three-way-match fields.

Rationale: Rich invoice understanding unlocks tax, procurement, vendor master, and expense compliance use cases beyond basic AP automation.

Start with Argentina tax compliance.

Chose a focused tax-policy comparison use case over scaling all document-processing use cases at once.

Rationale: Argentina tax was painful, policy-driven, and already manually checked, making it a good proof-of-concept before selecting more countries.

Expose suggestions to reviewers rather than silently changing postings.

Chose Power BI dashboards with SAP data, Wingman suggestions, and explanations over automatic correction without review visibility.

Rationale: Tax users need to see posted data, AI suggestions, mismatches, and explanations before acting.

Evaluate inline versus periodic expense compliance.

Chose keep both Concur inline and Wingman batch options open over forcing one compliance-check workflow immediately.

Rationale: Periodic audits may be enough for policy reminders and issue discovery, while inline checks catch issues earlier.

Gotchas (what bit them)

Legacy invoice automation was too shallow for new business problems.

Root cause: OCR/basic ML extracted only enough fields for SAP three-way matching.

Resolution: Wingman builds a richer invoice data lake and LLM pipeline to understand broader invoice content.

Argentina tax classification was complex and manual.

Root cause: Tax law varies by state and product type, so invoices had to be manually compared against policy documents.

Resolution: Wingman extracts invoice content, compares it to Syngenta tax policy, and explains mismatches.

Correcting vendor data mid-flow interrupts invoice processing.

Root cause: Incorrect vendor names or bank details stop the process and require AP staff to contact the vendor and repair the workflow.

Resolution: Wingman can compare extracted invoice vendor details against SAP MDG before processing begins.

Expense compliance operating mode was unresolved.

Root cause: Syngenta had both inline Concur and periodic batch-audit options, each with different workflow implications.

Resolution: The team kept both capabilities available while debating which operating model to implement.

Dashboard screenshots used fake sandbox numbers.

Root cause: The demo exposed tax and supplier information, so values were sanitized.

Resolution: The presenter explicitly warned that numbers in the screenshots were fake and supplier details were blacked out.

Tax policy itself has to stay current.

Root cause: Wingman compares invoices against a compiled Syngenta tax policy, but someone still has to update that policy when tax law changes.

Resolution: A planned phase has Wingman monitor Argentina tax law and propose policy updates for human validation.

Evaluation

Syngenta evaluates Wingman through proof-of-concept completion, dashboard use by Argentina tax/legal users, match/mismatch comparisons against SAP postings, confidence scores, visual grounding, explanations, and model experiments around cost per page, accuracy, and performance. The speaker reports a completed POC for Argentina and technical capability proven for procurement spend reduction, but does not provide a formal confusion matrix or exact accuracy percentage in the transcript.

Metrics: POC completion for Argentina tax · match and mismatch counts in Power BI · confidence scores · visual grounding · LLM explanations · cost per page · accuracy · performance · country scaling readiness

Outcomes

• Syngenta completed a proof of concept for Argentina tax compliance.
• Power BI dashboards are available to tax and legal users in Argentina.
• Wingman identifies tax-code mismatches, explains why a tax classification is incorrect, and can flag currency mismatches.
• The indirect-spend reduction use case has proven technical capability and awaits scale-up.
• Next phases include AP chatbot workflows and tax-law monitoring with human-validated policy updates.

Syngenta reports 90 countries, more than 30,000 employees, about one million invoices per year, about two and a half million invoice-related documents per year, and roughly 4,000 Argentina invoices per month for the tax use case. The demo screenshots used fake sandbox numbers.