Учет ГСМ и топливных карт: сущности и контроль аномалий

Зачем автопарку строгий учет и что считать проблемой

Разрозненный учет ГСМ и топливных карт почти всегда заканчивается одинаково: топливо "исчезает" в мелочах. Где-то не приложили чек, где-то списали по норме "на глаз", где-то карта оказалась у другого водителя. В итоге растут расходы, появляются спорные операции и срываются сроки закрытия месяца.

Нормальный учет топлива автопарка отвечает на простые вопросы без догадок и ручных уточнений: кто заправлялся, на какой машине, где именно, сколько литров и на какую сумму, по какой карте и на какой лимит. И главное - почему это было допустимо и чем подтверждено. Если по любой транзакции нельзя быстро собрать понятную картину, значит, процесс не под контролем.

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

Граница ответственности тоже должна быть ясной. Обычно бухгалтерия отвечает за корректные списания и закрывающие документы, логистика - за маршруты, пробег и плановую потребность, служба безопасности (или внутренний контроль) - за разбор подозрительных случаев и дисциплину использования карт. Когда роли не разделены, все "временно" делают вручную и в итоге никто не отвечает за результат.

На старте нужны базовые вещи: единые сущности (карта, лимит, заправка, пробег, документ), правила валидации и список типовых нарушений. Продвинутые элементы (скоринг аномалий, сравнение с сезонными нормами, автоматические запросы объяснений) лучше добавлять позже, когда данные станут стабильными и полными.

Данные и источники: что собираем в первую очередь

Чтобы учет ГСМ и топливных карт не превращался в спор "кому верить", заранее договоритесь, какие данные считаются первичными, а какие подтверждающими. Обычно первичный факт - транзакция провайдера топливных карт, а подтверждение - документы и пробег.

Источники почти всегда одинаковые. От провайдера топливных карт приходят дата и время, АЗС, вид топлива, литры, сумма, номер карты и иногда идентификатор водителя. Из путевых листов берутся маршрут, водитель, задание, подписи и отметки выпуска/возврата. Одометр (фото или ввод) дает контроль пробега. GPS полезен как проверка реального маршрута и остановок, но лучше не делать его единственным источником.

Параллельно нужны обязательные справочники, иначе данные не будут "склеиваться": транспортные средства (ТС), водители, контрагенты (провайдеры, АЗС, сервисы), справочник АЗС/точек отпуска. Важно сразу определить, что считается "АЗС": юридическое лицо, бренд или конкретная станция с адресом и координатами.

С первого дня задайте единые правила: даты и часовой пояс (особенно если заправки бывают в разных регионах), валюта и НДС, единицы измерения (литры и километры), формат госномера и табельного номера водителя. Разнобойность в мелочах потом дает ложные отклонения.

Чтобы стартовать без перегруза, достаточно минимального набора:

• ТС, водитель, карта (с привязкой хотя бы к ТС или водителю)
• транзакции заправок (дата/время, АЗС, топливо, литры, сумма)
• показания одометра на начало и конец смены (или рейса)
• путевой лист как факт работы (номер, даты, подписи/статусы)
• справочник норм расхода хотя бы по ТС и типу топлива

Практичный подход: начните с одного подразделения на 2-3 недели, проверьте качество данных (пропуски, дубли, несовпадение литров и сумм) и только потом расширяйте охват.

Сущность "Топливная карта": поля и связи

Топливная карта - это "ключ" к любому списанию ГСМ. Если карта описана плохо, вы не сможете уверенно ответить на базовые вопросы: кто заправлялся, на каком авто, по какому бюджету, и действительна ли карта.

В карточке сущности важно хранить идентификацию и жизненный цикл. Полный номер карты лучше не сохранять в открытом виде: оставьте маску (например, последние 4 цифры) и отдельный внутренний идентификатор, чтобы безопасно сопоставлять транзакции провайдера с вашей системой.

Основные поля карты

Как правило, хватает набора, который помогает контролировать правила использования и быстро блокировать "висящие" карты:

• провайдер (эмитент/оператор) и внешний идентификатор в его системе
• тип(ы) топлива, допустимые по карте, и дополнительные ограничения (если есть)
• статус: активна, приостановлена, заблокирована, утеряна, закрыта
• дата выдачи, дата активации, дата блокировки/закрытия и причина (кто инициировал)
• маска номера карты (например, **** **** **** 1234) и признак "замена/перевыпуск"

Связи и ответственность

Карта почти всегда "живет" в контексте людей, техники и бюджета, поэтому полезны явные привязки: к водителю (основной держатель), к транспортному средству (основное ТС), к подразделению и к статье затрат. Также стоит предусмотреть ответственного (диспетчер/механик/финконтроль), чтобы было понятно, кто должен реагировать на инциденты.

Практика, которая экономит много нервов: вести историю замен и перевыпусков как отдельные записи. Водитель потерял карту, получил новую, а старая формально еще активна у провайдера. Без истории вы увидите две карты "на одного человека" и не поймете, какая должна работать. В истории фиксируйте дату события, причину, инициатора и связь "старая карта -> новая карта". Это же помогает в расследованиях, когда по "старой" карте внезапно появляются заправки уже после даты блокировки.

Сущность "Лимит" и правила применения

Лимит лучше делать отдельной сущностью, а не полем в карточке топливной карты. Так правила можно менять без перевыпуска карты, хранить историю, задавать разные ограничения для одной и той же карты в разных условиях и быстро объяснять, почему операция была разрешена или отклонена.

У лимита должна быть область действия: к чему он привязан. Это может быть конкретная карта, водитель, транспортное средство, подразделение или даже маршрут (например, командировка или доставка по фиксированному направлению). Важно, чтобы система понимала пересечения: один лимит действует на карту, другой - на водителя, и оба учитываются.

Какие бывают лимиты

Обычно хватает нескольких типов, которые комбинируются:

• по сумме (тенге) за период
• по литрам за период
• по количеству операций за период
• по времени: дни недели и часы (например, запрет ночных заправок)
• по продуктам/категориям: только дизель, запрет сопутствующих товаров

Поля и применение

Минимальный набор полей: период (день/неделя/месяц), пороги (жесткий запрет и мягкое предупреждение), дата начала и окончания, приоритет, статус (активен/черновик/архив), причина (зачем введен лимит), кто утвердил и когда.

Правило применения должно быть однозначным: при проверке операции выбирается самый приоритетный лимит в своей области, затем накладываются более общие (например, по подразделению), и действует самое строгое ограничение. Так проще объяснять результат контроля.

Исключения лучше оформлять не правкой лимита, а отдельными сущностями: разовый допуск (на одну операцию или на день) и временное повышение (с датой завершения и согласованием). Например, на неделю повышают литраж для автомобиля на дальний рейс, а после даты окончания лимит возвращается автоматически.

Сущность "Заправка": транзакции и атрибуты

Заправка в системе учета - это транзакция: факт списания денег по топливной карте с конкретными параметрами (когда, где, сколько и на какую сумму). Чек АЗС или акт от провайдера - это документы, которые подтверждают транзакцию. Их важно не смешивать: одна транзакция может иметь несколько подтверждающих документов, а часть транзакций сначала приходит без чека и требует проверки.

Базовая карточка заправки обычно включает:

• дата и время операции (и отдельно дата постинга, если провайдер присылает обе)
• АЗС: сеть, точка, адрес (или код станции)
• вид топлива, литры, цена за литр
• сумма, валюта, НДС (если применимо)
• идентификаторы: номер карты, ID транзакции у провайдера, внутренний номер операции

Чтобы разбирать спорные случаи, добавьте контекст: транспортное средство, водитель, показание одометра на момент заправки, а также геолокацию (если она приходит из терминала или мобильного приложения). Одометр полезно хранить в двух видах: введенное значение и подтвержденное (после сверки с путевым листом).

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

Практичное правило: храните "сырой" ответ провайдера (оригинальный JSON/XML или строку выгрузки) и дату получения. Когда возникает расхождение по сумме или времени, эти данные помогают быстро понять, что случилось: операция была перепроведена, скорректирована или пришла дублем.

Сущность "Документ": контроль чеков и сверка сумм

Документ в учете ГСМ нужен не ради архива, а чтобы каждая заправка имела подтверждение и сходилась по сумме и литрам. Обычно встречаются разные источники: фискальный чек с АЗС, счет-фактура или акт за период, а также реестр от провайдера топливных карт.

Минимальный набор полей для сущности "Документ": номер и дата, сумма, валюта, ИИН/БИН покупателя (если указан), БИН (и при необходимости РНН) АЗС, признаки фискализации (ФД/ФП) и данные QR (как строка или разобранные поля). Отдельно храните тип документа и канал получения (фото от водителя, выгрузка, бумага).

Связь с заправкой делайте гибкой. Чаще всего это 1 к 1 (чек на одну операцию), но встречается 1 ко многим, когда один акт или счет закрывает пакет заправок за неделю или месяц. Тогда документ связывается с набором транзакций и хранит период.

Для контроля достаточно коротких статусов:

• получен
• проверен
• не сходится
• отсутствует
• отклонен

Практика, которая действительно работает: хранить скан или фото, фиксировать кто и когда проверил, и по каким данным сверял. Если в реестре провайдера 12 300 тг и 35,0 л, а в чеке 12 800 тг, статус сразу "не сходится" и создается задача на уточнение (ошибка цены, неверная АЗС, чужая карта или ручная корректировка).

Сущность "Пробег": как фиксировать и подтверждать

Пробег лучше хранить отдельной сущностью, потому что нормы расхода считаются от километров. В учете ГСМ и топливных карт заправка сама по себе мало что говорит: 60 литров могут быть нормой на трассе и аномалией, если машина почти не ездила.

Источники пробега часто разные и не всегда совпадают: одометр (фото панели), путевой лист, GPS-треки, сервисные записи (ТО, замена масла). Надежнее не выбирать один источник, а хранить "как есть" и отмечать степень доверия.

Минимальный набор полей у записи пробега:

• дата/смена
• ТС (vehicle_id) и при необходимости водитель (driver_id)
• начальный и конечный одометр
• км за период (расчетное поле)
• источник (одометр, путевой лист, GPS, сервис)
• доверие/статус подтверждения (например: черновик, подтверждено, спорно)

Валидации стоит делать жесткими. Одометр не может уменьшаться, а "прыжки" пробега должны сразу помечаться флагом: например, резкий рост за день, который не подтверждается GPS или маршрутом. Полезно также проверять разницу между одометром и GPS-пробегом: это не всегда мошенничество, но почти всегда повод запросить подтверждение.

Связи важны, если есть пересадки водителей. Пробег логичнее привязывать к ТС как к основному объекту, а водителя хранить как атрибут периода. Тогда проще считать норму по машине и разбирать отклонения по конкретным сменам и людям.

Сущность "Норма расхода": структура и версионирование

Норма расхода нужна, чтобы сравнивать "как должно быть" с фактом заправок и пробега. Удобнее хранить норму как базовую ставку (л/100 км) и набор коэффициентов условий. Так вы не плодите десятки почти одинаковых норм и получаете прозрачный расчет.

Структуру лучше строить по уровням, от общего к частному. Система должна уметь найти наиболее точную норму, а если ее нет - аккуратно откатиться к более общей.

Уровни норм (приоритет)

Обычно хватает 3-4 уровней: для модели ТС, для конкретного ТС (если оно "особенное"), для типа маршрута (город, трасса, смешанный), и для сезона. Например, для одного и того же автомобиля в январе по городу будет одна норма, а летом по трассе - другая.

В карточке нормы держите минимум: базовая ставка л/100 км, коэффициенты (город/трасса, зима/лето, нагрузка или масса груза, кондиционер или спецоборудование), единицы измерения и правила округления. Важно хранить не только числа, но и способ применения: умножение, добавка в л/100 км или отдельная надбавка.

Версионирование и утверждение

Нормы меняются, поэтому срок действия обязателен: дата начала, дата окончания (или признак "действует"), причина изменения. Не перезаписывайте старую норму, иначе потеряете корректную историю отклонений.

Добавьте поля контроля: кто утвердил, дата утверждения, основание (например, приказ или регламент), статус (черновик, на согласовании, утверждено, архив). Это помогает в спорах: почему в прошлом месяце "перерасход" был нормой, а в этом уже нет.

Сущность "Отклонение": расчет и разбор причин

"Отклонение" связывает факт заправок и пробег с ожидаемым расходом. Именно здесь учет ГСМ и топливных карт становится управляемым: вместо споров "много или мало" появляется понятный расчет и список причин.

Ожидаемый расход обычно считают так: подтвержденный пробег за период умножают на норму расхода (л на 100 км) и делят на 100. Дальше добавляют коэффициенты, если они у вас есть: сезон (зима), городские условия, перевозка груза, работа кондиционера, рельеф. Коэффициенты должны быть формализованы и привязаны к правилам, иначе отклонения станут субъективными.

В карточке отклонения удобно держать:

• период (дата от и до) и подразделение
• ТС, водитель (или экипаж), маршрут/объект (если применимо)
• факт: литры (сумма заправок) и при необходимости факт пробега
• ожидание: литры по расчету и примененные коэффициенты
• итог: отклонение в литрах и в процентах, комментарий

Разбор причин лучше вести через справочник причин и короткое пояснение. Частые варианты: долгие простои с работающим двигателем, прогрев зимой, пробки, работа спецоборудования (например, подъемник), неучтенные поездки или смена маршрута.

Чтобы процесс не зависал, задайте статусы и ответственных. Практичный набор: на проверке, подтверждено, отклонено (ошибка данных), списано по причине (с указанием причины и документа).

Пример: за неделю ТС проехало 620 км, норма 12 л/100 км. Ожидание 74,4 л. По чекам прошло 92 л. Отклонение +17,6 л. Проверка показывает 2 часа работы гидроборта и прогревы по утрам. Если это подтверждается путевым листом и заявкой на работы, отклонение списывают по причине.

Для отчетности делайте витрину: отклонение (л и %), доля списаний по причинам, количество кейсов "на проверке". Разрезы по подразделениям, ТС и водителям быстро показывают, где проблема в дисциплине, а где - в нормах или данных.

Практика выявления аномальных заправок: правила и скоринг

Аномальная заправка - это операция, которая выглядит правдоподобно по сумме, но плохо сходится с реальной эксплуатацией. Полезнее не искать один "идеальный" признак, а собрать несколько простых сигналов и присваивать каждой заправке риск.

Быстрые детекторы, которые ловят большинство случаев

Начните с правил, которые не требуют сложных данных и легко объясняются водителю и бухгалтерии:

• две и более заправки подряд за короткое время (например, в пределах 1-2 часов)
• ночные, выходные и праздничные заправки, если по графику машина не работает
• "физика не сходится": литров больше объема бака или расчетный расход на км в 2-3 раза выше нормы
• география: заправка далеко от обычной зоны работы или вне ожидаемого маршрута
• цена заметно выше средней по региону и периоду (с поправкой на тип топлива)

Скоринг: как собрать приоритет проверки

Каждому признаку задайте вес (например, 1-5). Итоговый риск = сумма весов с учетом критичности. Пример: ночная заправка (2) + вне географии (3) + "слишком быстрый расход" (4) = 9 баллов, это верхний приоритет.

Важно хранить причины срабатывания: не просто "красная операция", а список флагов. Тогда спор решается быстрее.

Дальше помогает короткий регламент проверки: запросить чек и фото/скан, сверить дату, время, АЗС, литры, цену; сверить с путевым листом, пробегом и маршрутом; уточнить у водителя причину (объезд, простои, пробки, смена задачи). При повторяемости стоит проверить лимиты, доступ к карте и закрепление карты. Итог фиксируется явно: подтверждено, ошибка данных, нарушение, и какие меры приняты.

Так вы снижаете ручную проверку: большинство операций проходит автоматически, а спорные попадают в верх списка.

Пример сценария: неделя учета и разбор спорных операций

В автопарке 12 машин и 20 топливных карт. Часть водителей пересаживается между ТС, поэтому "карта привязана к машине" не работает. На практике удобнее считать, что карта привязана к договору и лимитам, а факт использования всегда фиксируется связкой: карта + водитель + автомобиль + время.

В течение недели данные приходят из трех источников: транзакции по картам, показания одометра (или путевые листы), и документы АЗС (чеки, счета). Чтобы спорные операции разбирались быстро, каждая заправка хранит минимум: card_id, driver_id, vehicle_id, ts, azs_id, город/координаты, вид топлива, литры, сумма, валюта, код авторизации, а также контрольные поля: текущий лимит на момент операции и емкость бака ТС.

Три спорные операции

Первая: две заправки с разницей 30 минут. Для разбора нужны точные время и место, идентификатор АЗС/колонки (если есть), а также контекст смены: кто был водителем, какая машина, и какой был одометр перед первой заправкой. Дальше проверка простая: физически возможно ли израсходовать столько топлива за 30 минут, и не превышена ли емкость бака при сумме двух транзакций.

Вторая: пробег за день 40 км, а топлива списано 60 л. Отклонение считается так: берется норма расхода для этого ТС (и условий, если вы их ведете), например 12 л/100 км. Ожидаемый расход: 40 * 12 / 100 = 4,8 л. Отклонение: 60 - 4,8 = 55,2 л. Дальше важно зафиксировать причину: слив, неверный одометр, работа на холостом ходу, поездка не внесена в пробег.

Третья: чек загружен, но сумма не сходится с транзакцией. В сущности "Документ" удобно вести статусы: "получен", "на сверке", "расхождение", "запрошено уточнение", "закрыто", и хранить обе суммы, величину расхождения и комментарий.

Чтобы закрывать такие вопросы за 15 минут, помогают несколько понятных отчетов и очередей: уведомления о повторной заправке в короткий интервал, отчет "литры vs пробег" по дням и водителям, список документов со статусом "расхождение" и дедлайном, топ операций по превышению лимита и по емкости бака, карточка спора с таймлайном (транзакция, пробег, документ, решение).

Частые ошибки в учете и как их избежать

Самые дорогие проблемы в учете ГСМ обычно не про формулы, а про данные и дисциплину. Ошибка выглядит как мелочь, но через месяц превращается в спор с водителем, бухгалтерией или провайдером.

Одна из частых ловушек - смешивание сущностей. Например, лимит записывают прямо в карточку топливной карты и просто перетирают старое значение. В итоге невозможно понять, когда и кто менял лимит, и почему в конкретную неделю перерасход считается нормой. Решение простое: лимит хранить отдельной сущностью с датами действия и причиной изменения, а карта только ссылается на активный лимит.

Вторая проблема - разное время. Транзакции от АЗС могут быть в местном времени, в UTC или с переходом суток на стыке смен. Отсюда появляются дубли и расхождения по датам, особенно при ночных заправках. Помогает единое правило: хранить исходное время провайдера, нормализованное время в системе, и фиксировать часовой пояс. На сверках сравнивать по идентификатору транзакции, а не только по дате и сумме.

Часто игнорируют отмены и корректировки: провайдер присылает reversal или корректирует литраж, а в учете остается исходная операция. Тогда расход и отклонения начинают жить своей жизнью. Нужен статус транзакции (черновик, подтверждена, отменена, исправлена) и связь исправления с исходной записью.

Еще одна ошибка - не хранить первичные данные. Если нет сырых выгрузок, оригинальных чеков и полей провайдера, спорную заправку нечем доказать. Минимум, что стоит сохранять: оригинальный ответ провайдера, чек (скан/фото), и контрольные поля (номер АЗС, колонка, авторизация, итоговая сумма).

Наконец, документы часто проверяют выборочно и без понятных статусов. Лучше ввести короткий цикл контроля:

• новый чек: ожидает загрузки
• загружен: на сверке
• совпало: принято
• расхождение: спор/запрос уточнения
• закрыто: решение и комментарий

Так споры не копятся, а отклонения по учету ГСМ и топливных карт становятся объяснимыми и проверяемыми.

Внедрение шаг за шагом: от пилота до регулярного контроля

Начните с базы данных: если справочники "плавают", дальше любой учет ГСМ и топливных карт превращается в ручные правки. В пилоте важно договориться о единых названиях и уникальных идентификаторах.

План внедрения

Соберите минимальный контур и закрепите ответственность. Удобно идти такими шагами:

• утвердите справочники: ТС (госномер, модель, бак), водители, подразделения, АЗС (ID сети, адрес, тип топлива)
• опишите лимиты и нормы: по ТС, по водителю или подразделению, а также правила исключений (командировки, сезон, спецтехника); назначьте, кто их меняет и кто утверждает
• настройте загрузку транзакций и реестров от провайдера карт: единый формат времени, валюты, НДС, привязка к карте и ТС; сразу задайте правила дублей (например, одинаковые номер операции + сумма + время)
• включите контроль документов: чек/УПД обязателен, без него операция уходит в очередь на разбор; параллельно включите очередь проверки аномалий по простым правилам (слишком частые, сверх объема бака, ночью в выходные, не та АЗС)

Чтобы контроль не был "для галочки", используйте короткий критерий готовности операции к закрытию месяца:

• есть пробег за период и понятно, кто его подтвердил
• есть документ (чек/реестр) и он читаемый
• сходятся суммы и литры между транзакцией и документом
• отклонение от нормы посчитано и причина записана (ошибка, режим работы, погода, простой, маршрут)
• по аномалии есть решение: принять, запросить пояснение, удержать, открыть расследование

Дальше запускайте пилот на 1-2 подразделения на 2-4 недели и фиксируйте, что ломается чаще всего: отсутствие пробега, "левые" АЗС, потерянные чеки, спорные лимиты. После пилота масштабируйте по шаблону и не меняйте правила каждую неделю.

Если внедрение идет как интеграционный проект, инфраструктуру и поддержку удобно заранее продумать: где хранить реестры и сканы, на чем будут работать бухгалтерия и диспетчеры, кто отвечает за поддержку. В Казахстане такие задачи часто закрывают в связке с системным интегратором и производителем оборудования, например GSE.kz, когда нужны серверы, рабочие места и единая поддержка по эксплуатации 24/7.