# Revenue assurance — контроль полноты доходов оператора

URL: https://fw-t.ru/glossary/revenue-assurance
Опубликовано: 2026-09-14 · Обновлено: 2026-10-02

Revenue assurance — практика поиска потерь дохода между сетью и счетом: неучтенные события, ошибки тарификации, расхождения между системами.

**Коротко.** Revenue assurance — систематическая проверка того, что все оказанные услуги дошли до счета и были посчитаны верно. Потери возникают на стыках: событие не доехало от сети до биллинга, тариф применился не тот, пакет списался дважды, услуга активирована без начисления. Практика ищет такие расхождения регулярно, а не по факту жалобы.

## Как устроен контроль

Revenue assurance строится на сверках между системами, через которые проходит услуга: сеть, [медиация](/glossary/mediaciya), биллинг, учет платежей. Для каждой пары систем задается правило: какие записи должны совпасть и в каком объеме. Сверки идут по расписанию, найденное расхождение получает ответственного и разбирается до причины. Исправленная настройка закрывает весь класс таких потерь сразу.

## Типовые проверки

Набор сверок зависит от архитектуры оператора. Базовые проверки такие:

- события, зафиксированные оборудованием, против записей, дошедших до медиации;
- записи медиации против начислений в биллинге;
- услуги, активные в сети, против услуг на лицевых счетах;
- тарифные настройки против утвержденных условий;
- собственный расчет межоператорского трафика против встречного счета партнера.

## Чем отличается от антифрода

[Антифрод](/glossary/antifraud-telecom) ищет умышленные схемы: подключение по чужим данным, обход тарифов, перепродажу трафика. Revenue assurance ищет ошибки настройки и процессов, за которыми нет умысла. Методы пересекаются: и ошибка, и схема видны как расхождение между сетью и расчетом. Природа расхождения выясняется при разборе, после чего им занимается служба безопасности или администратор тарифов.

## Когда риск выше

Новые расхождения обычно появляются вместе с изменениями: запуском тарифа, подключением узла сети, переносом базы на другую систему. При миграции параллельная работа старого и нового контура на одних событиях дает самую полную сверку. При объединении нескольких биллингов в один расхождения становятся видимыми, потому что одни и те же услуги оказываются описаны по-разному.

## В платформе Forward

Отдельного продукта класса revenue assurance в каталоге Forward нет. Сверки строятся на данных расчетного контура: [Forward Billing](/products/fw-billing) хранит начисления и тарифные настройки, в аналитическом хранилище [Forward DMP](/products/fw-dmp) собираются витрины для регулярных сверок и отчетов. Виды потерь и порядок их поиска разобраны в статье [о фроде в биллинге](/articles/63-billing-dlya-telekoma-kak-izbezhat-froda-privlech-klienta-i-rabotat-s-bolshimi-dannymi).