Quartz 4

Invoice_Mapping

3 min read

Invoice Mapping

What is being mapped?

Invoice Mapping transforms Oracle invoice data into SAP S/4HANA invoice documents.

This includes:

  • Supplier invoices
  • Financial postings
  • References to procurement documents

Core Transformation

Oracle → SAP

  • Oracle Invoice → SAP Invoice (MIRO / FI document)

BUT:

→ Oracle invoice = loosely linked record
→ SAP invoice = tightly validated process document

Key Principle

You are NOT mapping invoices
You are validating financial truth against process history

SAP checks invoices for correctness against procurement documents before posting. ([turn0search0])

Mapping Strategy

Step 1: Identify Invoice Type

From Oracle:

  • PO-based invoices
  • Non-PO invoices

Map to:

  • PO-based → SAP MM Invoice
  • Non-PO → SAP FI Invoice

Step 2: Map Supplier (BP)

  • Oracle Vendor → SAP Business Partner (Supplier Role)

Critical: → Supplier MUST exist before invoice

If missing: → Invoice fails immediately

For PO-based invoices:

Must reference:

  • Purchase Order (PO)
  • Goods Receipt (GR)

This is NOT optional.

SAP requires invoice to align with procurement documents for validation.

Step 4: Handle 3-Way Match

SAP enforces:

PO ↔ GR ↔ Invoice

Checks:

  • Quantity
  • Price
  • Supplier

If mismatch: → Invoice blocked

Invoice verification ensures correctness of price, quantity, and data before posting. ([turn0search0])

Step 5: Map Financial Data

Invoice must include:

  • Amount
  • Currency
  • Tax
  • Account assignment

SAP creates: → FI document automatically

Step 6: Handle Tax Mapping

From Oracle:

  • Tax codes / percentages

To SAP:

  • Tax codes
  • Jurisdiction rules

Errors here: → Financial misstatements
→ Compliance issues

Step 7: Number Mapping

Options:

Option 1: Preserve Invoice Number

  • Oracle Invoice ID = SAP Reference

Option 2: SAP-generated

  • Store Oracle ID as reference field

Invoice number must remain traceable for audit.

Step 8: Timing & Sequence

Invoice must follow:

  1. PO exists
  2. GR exists
  3. THEN invoice

If violated: → Posting fails

Mapping Logic

→ [Google Sheet: Transactional Mapping.xlsx]

Contains:

  • Field-level mapping
  • Transformation rules
  • Default values

Markdown explains logic
Excel defines execution

Process Impact

→ P2P_Procure_to_Pay

Invoice drives:

  • Financial posting
  • Liability creation
  • Payment processing

Incorrect invoice: → Blocks payment
→ Corrupts financials

Validation

→ Transactional_Validation

Key checks:

  • PO–GR–Invoice consistency
  • Supplier correctness
  • Tax accuracy
  • Amount reconciliation

Common Issues

→ Cross_System_Issues

Typical failures:

1. Missing PO Reference

→ Invoice cannot be validated

2. Missing GR

→ Invoice blocked

3. Price Mismatch

→ Invoice blocked

4. Tax Mismatch

→ FI errors

5. Duplicate Invoice

→ Double payment risk

Anti-Patterns

❌ Treat invoice as standalone record
❌ Ignore PO/GR linkage
❌ Skip tax validation
❌ Allow sequence violations

Key Takeaway

Invoice mapping is NOT:

→ Data migration

It is:

→ Financial validation against business process

If this is wrong:

  • Payments stop
  • Financials are incorrect
  • Audit issues appear

And SAP will block you before you can pretend otherwise

Backlinks