Fiori analytics for order-to-cash not updating after billing

Our Fiori analytical apps for order-to-cash cycle are showing outdated data after billing documents are posted. The KPI tiles on the launchpad display revenue and invoice counts that are 2-4 hours behind actual postings in VF01/VF04. We’re on S/4HANA 1809 and using standard Fiori apps for sales analytics.

I’m trying to understand if this is a data replication issue versus a live CDS view problem. When I check the billing tables directly in SE16, the data is there immediately, but the analytics don’t reflect it. Could this be related to how the billing document tables are joined in the underlying CDS views, or is there some kind of analytics cache that needs refreshing?

Our business users are complaining because they make decisions based on these dashboards, and the delay is causing issues with credit management and collections follow-up.

Your issue involves all three focus areas - let me address each systematically:

Data Replication vs. Live CDS:

In S/4HANA 1809, standard order-to-cash Fiori apps like “Manage Billing Documents” and “Sales Revenue Analysis” can operate in different modes. First, identify which mode you’re in:

  • Check transaction SBIW_CDS for CDS view extraction settings
  • Look at your Fiori app configuration in /UI2/FLPD_CUST to see if it points to live CDS views or BW queries
  • If you see InfoProvider references or BW extractors (2LIS_13_VDITM for billing), you’re using replicated data

The 2-4 hour delay strongly suggests you’re using BW extraction with scheduled delta loads. Live CDS views would show data within seconds to minutes.

Billing Table Joins:

The standard billing CDS views (like I_BillingDocument and I_BillingDocumentItem) read directly from VBRK/VBRP and should reflect data immediately after VF01 posting. However, analytical KPIs often join multiple entities:

  • VBRK/VBRP (billing header/items)
  • VBAK/VBAP (sales order references)
  • KNA1/KNVV (customer master)
  • BSID (accounting documents for revenue)

If your KPIs include financial data (actual revenue vs. billed amount), there’s a dependency on FI posting completion. Check if your billing document creation is configured for immediate accounting document generation (VOV8 transaction, billing type configuration). If accounting posts in background (program RV60SBAT), that’s your delay.

Analytics Cache Refresh:

Fiori analytical apps use multiple caching layers:

  1. OData Service Cache: Check /IWFND/MAINT_SERVICE, find your service (typically /IWBEP/CL_V4_ABS_PM_MODEL_PROV or similar), and verify cache-control headers. Default is often 300-600 seconds.

  2. CDS View Buffer: Some analytical CDS views use result caching. Check the view definition for @ObjectModel.resultCache annotations.

  3. Browser/Gateway Cache: Fiori launchpad tiles cache data locally. This is typically 5-10 minutes.

Immediate Solution:

For live analytics with minimal delay:

  1. Verify your apps use live CDS views by checking the OData service definition
  2. Reduce OData cache time: /IWFND/MAINT_SERVICE → Select service → Configure → Set max-age=60
  3. Ensure immediate FI posting: Transaction VOV8 → Select billing type → Set “Accounting document creation” to “Online”
  4. For existing cached data, run program /IWFND/CL_CACHE_CLEANUP or restart ICM (transaction SMICM)

Verification Steps:

  1. Post a test billing document in VF01
  2. Immediately check VBRK table (SE16) - should see record within seconds
  3. Wait 1-2 minutes, refresh Fiori app - if still no data, it’s a cache or replication issue
  4. Check ST05 SQL trace while refreshing the app to see which tables are being queried

Long-term Recommendation:

For S/4HANA 1809 order-to-cash, migrate to embedded analytics using live CDS views. This eliminates BW extraction delays. The standard apps support this - you just need to reconfigure the OData services to use CDS-based data sources instead of BW InfoProviders. This requires some Fiori configuration changes but gives you near-real-time analytics (under 1-minute delay typically).


This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

Check if you’re using embedded analytics or if data is being replicated to BW. In 1809, some standard Fiori apps still use BW extraction which has scheduled delta loads. That would explain your 2-4 hour delay. Go to transaction RSA3 and check the extractor schedules for billing documents.

This sounds like a CDS view cache issue to me. Fiori apps cache analytical queries for performance reasons. Try transaction /IWFND/MAINT_SERVICE and check your OData service cache settings. You might need to reduce the cache expiration time or force a refresh after billing posts. Also verify the $metadata of your OData service to see if it’s marked as cacheable.

I had a similar issue and it turned out the CDS views weren’t using the right billing tables. Standard S/4HANA billing uses VBRK/VBRP, but some custom scenarios write to different tables first. Check your CDS view definition - is it reading directly from VBRK or going through intermediate views? If there are multiple view layers with associations, data might not propagate immediately. Also look at whether @Analytics.dataCategory is set correctly on the consumption view.

In 1809, the order-to-cash Fiori apps can use either live CDS views or replicated data depending on configuration. The fact that you see data in SE16 immediately but not in analytics suggests the CDS views might be using buffering or there’s a scheduled job that updates analytical snapshots. Check transaction RSANWB_CDS to see if your billing CDS views are registered for analytical queries and what their refresh mode is. You might have delta queue processing that runs periodically rather than real-time updates. For true real-time analytics, you need CDS views with @Analytics.query: true and no intermediate buffering layers.

Confirmed this resolves the delay issue — checking /UI2/FLPD_CUST revealed our Sales Revenue Analysis app was pointing to BW queries fed by 2LIS_13_VDITM, not live CDS views.

Have you checked if accounting documents are being created in real-time or in background? Sometimes billing posts immediately but the FI document creation is scheduled, which can cause analytics delays if your KPIs include revenue recognition data that depends on accounting postings.