引入OCS的初衷之一是為了讓計費系統能夠參與到用戶的通訊控制中來，也就是所謂的實時信控。用戶在沒有余額時，通訊就會被停止，不會造成”天價欠費 ”，一方面保障用戶的利益，一方面也保障了運營商的利益。由於OCS要進行實時信控，所以在通話結束后，會將產生的費用實際扣除，稱為實扣；而OFCS則不同，由於在后付費支撐那邊的慣性，需要支撐固網的后付費業務，所以余額就不能實扣，而是先將產生的費用累計起來，作為“當月實時費用”到月底對余額進行批沖，再將費用扣除，稱為虛扣。
實扣和虛扣已經事實上成為一種“業務規則”，。由於實扣和虛扣對余額的處理方式不一致，造成很多業務規則的實現上實際也不一致，最典型的是OCS和OFCS在用戶提醒上，按照OFCS的規則，用戶查詢余額時，需要提醒用戶余額，當月的實時費用，可用余額，這幾個值按照實際值填好即可，是按照用戶余額-當月實時費用=可用余額的邏輯。但是對於OCS，由於用戶的余額為實扣，則用戶余額是反算出來的，是用戶余額=當月的實時費用+目前余額的邏輯，所以，雖然給用戶的查詢結果一致，但是實際的處理方式確實不一樣的，發票打印上的本期余額和上期余額實際也有類似的問題。
這實際上已經成為統一服務的一個比較大的“負擔”。甚至有些問題，業務規則的制定者也不一定清楚詳情。比如OCS側帳務優惠的處理。假設某套餐存在滿100送20元的優惠，在OFCS的系統，帳務優惠是很清晰的，如果到了月底，用戶消費101元，送出那最終的計費結果就只有81元，月底再將這筆虛扣的錢進行銷帳。但是對於OCS，用戶消費的101元已經實扣，到月底的時候，就需要給用戶返20元到余額帳本中，問題就來了，假設用戶有多個帳本，按照什么順序執行扣費順序，又該往哪個帳本返還呢？這個規則實際很多人都沒弄清楚。
舉個極端的例子，比如說用戶有11元本金帳本，每月有個划撥的贈送90元（保底消費90元）的帳本，贈送帳本需要先扣，那贈送的90元的先扣掉了，本金的11元再扣掉，那么返還的時候，如果20元都送到本金，那么用戶本金平白無故增加了9元，這9元實際不是用戶本金存入的，用戶明顯占了便宜，財務上也會造成不平，如果全部返還到贈送帳本上，那也有問題，用戶的划撥帳本沖入20元后，又會被保底消費把這個20元扣掉，那等於給用戶沒贈送。正確的做法應該是后扣費的先返還，先扣費的后返還。先給用戶返回11元到本金帳本，再給用戶返9元到贈送帳本，最后用戶划撥的90元帳本被保底消費扣完，而本金剩余11元。
排除真正意義上的后付費用戶不說，准實時的預付費和實時預付費用戶的余額處理邏輯，應該要統一。那么到底該如何統一呢？下表中列了一下主要的處理差異：
| 涉及差異 |
實扣 |
虛扣 |
| 改造難度 |
高 |
低 |
| 計費效率 |
效率低 |
效率高 |
| 信控規則 |
簡單 |
復雜 |
| 帳務優惠 |
復雜 |
簡單 |
| 發票規則 |
需改造 |
不需改造 |
| 用戶查詢慣性 |
不遵循 |
遵循 |
| 支持靈活帳期 |
簡單 |
復雜 |
| 實時出帳 |
簡單 |
復雜 |
如果考慮現階段的業務，自然還是OCS改造為虛扣更加合適一些。首先是因為改造的難度，OCS改造為虛扣，對每一個帳本增加一個虛扣余額的字段，實時信控時也要參考這個字段，這一塊雖然改造難度以及涉及的周邊模塊的改動也不小，但是整體比OFCS做實扣的改動難度，還是要小很多。另外效率問題，帳務優惠的問題，用戶的習慣問題等都是用虛扣好一些。
但是如果要考慮將來的話，應該會得到不一樣的結論，從業務的發展角度去考慮，業務將向數據運營方向發展，更加注重用戶體驗。這方面，OCS比HB在實時信控上存在較大優勢（如AOC和針對內容的信控），OCS應該是計費發展的主流；數據業務的收入也勢必會超過語音業務，原來在語音業務這邊慣性思維的帳務優惠的套餐會越來越少；靈活帳期和實時出帳也能很好的提升用戶體驗。從技術發展的角度去考慮，PC化、雲化也是計費這邊的大勢所趨，OFCS也需要具備消息計費的能力，計費的流程勢必要統一，OFCS每條話單也需要更新帳本余額，而不是原來簡單的累加。原來考慮的效率問題就變得沒那么嚴重，而且雲化給計費帶來的效率提升是顯而易見的。