Phase 8: Advanced FI-CA (Collections & Mass Processing)

Prerequisite Check: Phases 1–7 must be complete. We need: FI-CA Document Types (Phase 2, Step 2.3), FI-CA Number Ranges (Phase 2, Step 2.2.2), Dunning Procedure ZAEP (Phase 2, Step 2.7), Payment Methods (Phase 2, Step 2.8), Account Determination (Phase 2, Step 2.5 + Phase 6, Step 6.1), and the production billing/invoicing pipeline (Phases 5–6). This phase automates the revenue cycle — payment processing, returned payment handling, dunning execution, and mass batch job scheduling.

⚠️ Architecture Constraint — FI-CA Subledger Isolation: All payment, collections, dunning, and write-off transactions in this phase operate exclusively within the FI-CA subledger. Do NOT configure standard FI-AR (Accounts Receivable) payment processing. The utility’s customer receivables exist only in FI-CA — the FI-GL General Ledger receives compressed summary postings via Reconciliation Keys and the FPG1 transfer process, never individual customer-level detail.

Section A: Reconciliation Keys (FI-CA → FI-GL Bridge — Prerequisite Injection)

⚠️ Critical Prerequisite: Before configuring any mass processing (payment runs, dunning runs, or the FPG1 General Ledger transfer), Reconciliation Keys must be fully understood and verified. While Phase 2 (Step 2.6) created the basic keys, this section documents the detailed architecture of how Reconciliation Keys automate the bridge between millions of FI-CA subledger documents and the compressed FI-GL postings via the ZC document type.

Step 8.1 — Reconciliation Key Architecture (Deep Dive)

Understanding the Problem Reconciliation Keys Solve

In a utility with 500,000 customers billed monthly, a single billing run (EA00 + EA19) generates 500,000+ individual FI-CA documents. The FI-GL General Ledger cannot — and should not — receive 500,000 individual journal entries. Instead, Reconciliation Keys provide the mechanism to:

1. Group millions of FI-CA documents by logical category
2. Compress them into a single summarized FI-GL journal entry per Reconciliation Key
3. Bridge the gap between subledger detail and general ledger summarization using the ZC document type

How Reconciliation Keys Are Generated

Reconciliation Keys are automatically assigned to every FI-CA document at the time of posting. The assignment is driven by:

FI-CA Document Creation (e.g., Invoice from EA19)
    │
    ├── System reads: Main Transaction (e.g., 0010 = Revenue)
    ├── System reads: Sub Transaction (e.g., 0010 = Residential)
    ├── System reads: Posting Date
    │
    └── Auto-assigns Reconciliation Key:
         ├── Key = 0001 (Revenue & AR)
         ├── Transfer Frequency = Daily
         └── FI-GL Doc Type = ZC

Reconciliation Key Configuration — Expanded Detail

Screen 1 — Verify/Extend Reconciliation Key Definitions

Navigate to the SPRO path above → click Execute (⏩).

Review and confirm the keys created in Phase 2, Step 2.6. Extend with the following detail:

Screen 2 — Summarization Variant Configuration

Each Reconciliation Key has a Summarization Variant that controls how much detail is retained during compression:

Click Save (Ctrl+S).

The FPG1 Transfer Process (End-to-End)

Step 1: FI-CA Subledger (500,000 documents)
════════════════════════════════════════════
Doc 1: ZI, CA 000200000001, $242.35, Recon Key 0001
Doc 2: ZI, CA 000200000002, $187.50, Recon Key 0001
Doc 3: ZI, CA 000200000003, $312.75, Recon Key 0001
...
Doc 500,000: ZI, CA 000299999999, $95.00, Recon Key 0001

Step 2: FPG1 Execution (T-Code: FPG1)
════════════════════════════════════════
Selection:
  Company Code: AEP1
  Posting Date: 07/01/2026
  Reconciliation Key: 0001

Step 3: Compression & Transfer
════════════════════════════════
FI-CA groups all 500,000 docs by Recon Key 0001
  → Summarizes by: Company Code + Posting Date + Main/Sub Trans
  → Creates ONE FI-GL document:

Step 4: FI-GL Document (Type: ZC, Number Range: 19)
════════════════════════════════════════════════════
Document: ZC 1900000001
Posting Date: 07/01/2026
Company Code: AEP1

| Line | G/L Account         | Debit         | Credit        | Text                           |
|------|---------------------|---------------|---------------|--------------------------------|
|  001 | 1200000000 (AR)     | $45,000,000   |               | Revenue & AR — Daily Transfer  |
|  002 | 4100000000 (Rev-Res)|               | $28,000,000   | Residential Revenue            |
|  003 | 4200000000 (Rev-Com)|               | $12,000,000   | Commercial Revenue             |
|  004 | 4300000000 (Rev-Ind)|               |  $5,000,000   | Industrial Revenue             |

Why This Step

Reconciliation Keys are the architectural cornerstone of the FI-CA → FI-GL bridge. Without them:

1. The G/L would receive zero utility revenue postings (balance sheet incomplete)
2. OR the system would attempt to post 500,000 individual G/L entries per billing cycle, causing severe performance degradation and storage consumption

The Reconciliation Key + Summarization Variant + ZC document type + FPG1 transfer constitutes a four-part architecture that maintains the integrity of both the detailed subledger (FI-CA) and the summarized general ledger (FI-GL).

Key Configuration Notes

• ⚠️ The ZC document type (Phase 1, Step 1.8) was specifically created for this transfer. It is the ONLY document type used in FPG1. Standard FI document types like SA must NOT be used for the subledger-to-GL transfer.
• Number Range 19 (Phase 1, Step 1.7) was reserved for FI-CA clearing/transfer documents. This ensures that reconciliation postings are easily identifiable in G/L reporting.
• The Summarization Level is critical for regulatory reporting — PUCO requires revenue reporting by rate class (Residential/Commercial/Industrial), so the Sub Transaction field must be retained in summarization. However, individual customer detail (CA, BP, Invoice Number) must be compressed to avoid G/L bloat.

Section B: Payment Runs (FPY1)

Step 8.2 — Configure Payment Lot Processing

SAP Screen Flow

Screen 1 — IMG Navigation

1. Navigate to the SPRO path above → click Execute (⏩).

Screen 2 — Payment Lot Configuration: Table View

2. Click New Entries.

Screen 3 — New Entry: Payment Lot Profile

3. Click Save (Ctrl+S).

Payment Source Configuration

Part B: Define Bank File Import Settings

SPRO Path: SPRO → Financial Accounting → Contract Accounts Receivable and Payable → Basic Functions → Payments → Payment Media → Define Incoming Payment File Formats

4. Click New Entries:

5. Repeat for each file format:

6. Click Save (Ctrl+S).

Step 8.3 — Execute Payment Run (FPY1)

SAP Screen Flow

Screen 1 — Payment Run: Selection Parameters

1. Execute FPY1.
2. Enter selection parameters:

3. Click Execute (⏩).

Screen 2 — Payment Run Results

Post-Payment Verification

Why This Step

The payment run (FPY1) is the cash collection engine of the utility. A regulated utility with 500,000 customers processes 300,000+ payments per month through various channels (ACH, lockbox, online portal, walk-in). Manual posting is impossible at this scale — FPY1 automates the entire cycle:

1. Ingest bank files containing thousands of payment records
2. Match each payment to the correct Contract Account
3. Post the payment as FI-CA document type ZP
4. Clear the corresponding open invoice item
5. Handle exceptions (partial payments, overpayments, unmatched)

Section C: Returns Processing

Step 8.4 — Configure Return Payment Processing

SAP Screen Flow

Screen 1 — IMG Navigation

1. Navigate to the SPRO path above → click Execute (⏩).

Screen 2 — Return Processing Configuration: Table View

2. Click New Entries.

Screen 3 — New Entry: Return Processing Profile

3. Click Save (Ctrl+S) → Double-click to configure return reasons:

Screen 4 — Return Reason Codes

4. Click New Entries for each return reason:

5. Click Save (Ctrl+S).

Part B: Return Processing Automation

Screen 5 — Automation Rules

6. Click Save (Ctrl+S).

Return Processing Flow

Bank Returns File (NACHA R-codes)
    │
    ├── FP07: System reads return file
    │
    ├── For each returned payment:
    │     ├── 1. Reverse original ZP document
    │     │     └── Original open item (ZI) reinstated
    │     │
    │     ├── 2. Post return fee ($25.00)
    │     │     └── New ZI document for the fee
    │     │
    │     ├── 3. Generate customer letter
    │     │     └── "Your payment of $242.35 was returned..."
    │     │
    │     └── 4. Update dunning level
    │           └── Dunning level +1 (accelerates collections)
    │
    └── If repeat return count ≥ 3:
          └── Block payment method on Contract Account
              └── Force customer to use alternative (e.g., cash, credit card)

Why This Step

Bounced checks and ACH returns cost the utility money (bank fees, processing labor, delayed cash flow). Returns processing automates the reversal, fee posting, and customer notification — without manual CSR intervention. The repeat return threshold protects the utility from chronic bad-check writers.

Key Configuration Notes

• ⚠️ PUCO Rule 4901:1-10-21 limits the maximum return check fee for residential customers. The configured fee amount must comply with the current tariff filed with the commission.
• When a payment is reversed, the original open item is reinstated. The customer now owes both the original invoice amount AND the return fee. This combined balance feeds into the dunning process.

Section D: Dunning Automation

Step 8.5 — Fine-Tune the Dunning Procedure (ZAEP)

Phase 2 (Step 2.7) created the ZAEP dunning procedure with 4 levels. This step fine-tunes the procedure with detailed automation rules and disconnect notice compliance.

SAP Screen Flow

Screen 1 — IMG Navigation

1. Navigate to the SPRO path above → click Execute (⏩).

Screen 2 — Dunning Procedures: Table View

2. Double-click on procedure ZAEP to open the detail view.

Screen 3 — ZAEP: Level Configuration — Extended Detail

3. Verify and extend each dunning level:

Level 1 — Friendly Reminder

Level 2 — Past-Due Warning

Level 3 — PUCO 14-Day Disconnect Notice

Level 4 — Service Disconnection

4. Click Save (Ctrl+S).

PUCO-Mandated Protections (Disconnect Blockers)

Why This Step

Dunning is the regulated collections process that escalates from a friendly reminder to service disconnection. State regulators (PUCO) impose strict requirements on:

• Notice periods — 14 days minimum before disconnection
• Notice content — must include amount, disconnect date, customer rights, and PUCO complaint contact
• Seasonal protections — winter moratorium prevents cold-weather disconnections
• Medical protections — customers with certified medical conditions cannot be disconnected

Step 8.6 — Execute Mass Dunning Run (FPDN)

SAP Screen Flow

Screen 1 — Dunning Run: Selection Parameters

1. Execute FPDN.
2. Enter selection parameters:

3. Click Execute (⏩).

Screen 2 — Dunning Run Results

Post-Dunning Verification

Why This Step

The mass dunning run (FPDN) processes all delinquent accounts in a single batch execution. In production, it runs as a daily scheduled job that:

1. Evaluates every open item against the dunning levels
2. Determines the appropriate action (letter, charge, disconnect notice)
3. Posts dunning fee documents to FI-CA
4. Creates disconnect work orders for Level 4 accounts
5. Respects all PUCO-mandated protections

Section E: Mass Activity Framework (Batch Job Scheduling)

Step 8.7 — Configure the Mass Activity Scheduling Framework

SAP Screen Flow

Screen 1 — IMG Navigation

1. Navigate to the SPRO path above → click Execute (⏩).

Screen 2 — Mass Activity Profiles: Overview

2. Define profiles for each recurring mass process:

Mass Activity Schedule (Production Batch Jobs)

Daily Revenue Cycle Timeline

Time     Process                  T-Code   Documents Created
──────   ───────────────────────  ──────   ─────────────────
06:00    Mass Billing (Com/Ind)   EA00     Billing orders
08:00    Mass Invoicing           EA19     FI-CA docs (ZI)
10:00    Payment Run (ACH)        FPY1     FI-CA docs (ZP) — items cleared
14:00    Payment Run (Lockbox)    FPY1     FI-CA docs (ZP) — items cleared
16:00    Returns Processing       FP07     Reversed ZP docs + fees
18:00    Mass Dunning             FPDN     FI-CA docs (ZD) + notices
23:00    G/L Transfer (Revenue)   FPG1     FI-GL docs (ZC) — Recon Key 0001
23:15    G/L Transfer (Payments)  FPG1     FI-GL docs (ZC) — Recon Key 0002

Monthly Revenue Cycle (Residential Billing)

Day 1:   Mass Billing (Residential)     EA00     ~500,000 billing orders
Day 1+2h: Mass Invoicing               EA19     ~500,000 FI-CA invoices (ZI)
Day 2-28: Daily Payment/Dunning Cycle   FPY1/FPDN  Ongoing collections
Day 30:  G/L Transfer (Dunning)         FPG1     Month-end dunning summary (ZC)
Day 31:  Period Close                    FAGL     Verify G/L balances match FI-CA

Why This Step

A utility’s revenue cycle generates millions of documents per month. Manual execution of billing, invoicing, payment, and dunning transactions is impossible at scale. The Mass Activity Framework provides:

1. Scheduled automation — jobs run at defined times without human intervention
2. Dependency chaining — each job waits for its prerequisite to complete
3. Parallel processing — large-volume jobs run across multiple application servers for performance
4. Monitoring — EMMA provides a single dashboard to monitor all mass activities

Key Configuration Notes

• ⚠️ Job dependencies are critical. If EA19 (invoicing) runs before EA00 (billing) completes, it will find no billing orders to process. If FPG1 runs before EA19, revenue will not yet be in the FI-CA subledger.
• Parallel processing configuration depends on the number of available application server work processes. The SAP Basis team must allocate dialog and batch work processes accordingly.
• The EMMA monitor provides real-time status: Running, Completed, Error. Production support teams should configure email alerts for any job that ends in Error status.

Step 8.8 — Configure the G/L Transfer Run (FPG1)

SAP Screen Flow

Screen 1 — G/L Transfer: Selection Parameters

1. Execute FPG1.
2. Enter selection parameters:

3. Click Execute (⏩).

Screen 2 — G/L Transfer Results

Post-Transfer Verification

Why This Step

FPG1 is the final step in the daily revenue cycle. It ensures that the FI-GL General Ledger reflects the cumulative financial position of the utility’s customer base. Without this transfer:

• The balance sheet AR balance would be stale
• Revenue P&L accounts would not reflect current-period billing
• Month-end close would fail regulatory audit

Phase 8 — Completion Checklist

What Comes Next?

With Phases 1–8 complete, the utility has a fully operational revenue cycle:

End-to-End Revenue Cycle (Complete)
═══════════════════════════════════

AMI Meter (15-min Interval Data)
    ↓
EDM Processing (Validation → Replacement → TOU Bucketing)
    ↓
Billing Engine (EA00 — Operands × Rates → Bill Calculation)
    ↓
Invoicing (EA19 — FI-CA Document + Print Document)
    ↓
Bill Distribution (Print / Email / Portal)
    ↓
Payment Collection (FPY1 — ACH / Lockbox / Portal / Walk-in)
    ↓
Returns Processing (FP07 — Bounce → Reverse → Fee → Letter)
    ↓
Dunning / Collections (FPDN — Reminder → Warning → 14-Day Notice → Disconnect)
    ↓
G/L Transfer (FPG1 — FI-CA Subledger → FI-GL via Reconciliation Keys)
    ↓
Financial Reporting (Balance Sheet + P&L — Regulatory Filings)

Future Configuration Phases (Not Covered Here)

🔗 Return to Implementation Overview for the full phase map.