Faktureringssystem för snöröjning: det här ska du kräva

Fråga en snöröjningsentreprenör vilken månad som är värst, så får du höra om januari. Fråga den som sköter ekonomin, så får du höra om april: månaden då en hel vinter ska rekonstrueras ur körjournaler, sms-trådar och minne, och bli fakturor som kunderna faktiskt betalar. Varje timme med plogen verkar skapa tio minuters arkeologi i efterhand, och varje oklarhet slutar på något sätt till kundens fördel.

Ett faktureringssystem för snöröjning finns till för att ta bort den månaden. Inte genom att göra fakturorna snyggare, utan genom att ändra var de kommer ifrån: i stället för att skrivas i efterhand skapas fakturaraderna automatiskt ur det som registrerades ute på fältet, i samma stund som arbetet bekräftas. Den här guiden visar hur det ser ut och vad du ska kräva av ett system du utvärderar.

Innehåll

• Fem sätt att prissätta snöröjning
• Var fakturaraderna ska komma ifrån
• Vilket pris som hamnar på raden
• Skyddsnäten: dubbletter, nollor och saknade priser
• Avräkning med underentreprenörer från samma underlag
• Överlämningen till bokföringen
• Frågor att ställa till leverantören
• Sammanfattning och nästa steg

Fem sätt att prissätta snöröjning

Ett faktureringssystem för vinterunderhåll måste tala flera prisspråk, ofta på samma gata:

• Per uppdrag. Arbetshästen. Varje utfört besök blir en rad till adressens pris för arbetstypen. Två utkall samma dag ger två rader, och ett bra system flaggar den andra som en möjlig dubblett så att en människa får avgöra, i stället för att bestämma själv.
• Per timme. Radens antal är den registrerade tiden på plats: utcheckning minus incheckning, med två decimaler. Det fungerar bara när tiderna registreras automatiskt, vilket är varför bra fakturering egentligen är en fråga om data från fältet. I guiden om GPS-spårning går vi igenom var tiderna kommer ifrån.
• Per säsong. Kunden betalar ett fast belopp, uppdelat på delbetalningar ("Säsongsavgift 1 av 2", "2 av 2" och så vidare) över den säsong du har ställt in. Utförda besök ger inga kundrader per besök, men arbetet registreras ändå och syns. Den BRF som betalar under en snöfri december kan se exakt vilken beredskap den betalar för.
• Per uppdrag efter snödjup. Priset beror på hur mycket snö som föll: adressen har djupintervall i centimeter och ett pris per arbetstyp och intervall, och varje utfört besök prissätts efter det registrerade snödjupet. Det passar avtal där en lätt snöbyge och ett rejält snöfall inte ska kosta lika mycket.
• Inget pris än. Den ärliga varianten. Många adresser kommer igång innan priset är avtalat. Systemet ska inte fakturera något, men inte heller glömma något: varje utfört stopp förblir fakturerbart, och i samma stund som ett riktigt pris sätts på adressen erbjuder systemet att fakturera säsongens ofakturerade arbete i efterhand.

En sak till som är värd att kräva: pristyp per arbetstyp på samma adress. Sandning per uppdrag och plogning per timme på samma fastighet är ett helt vanligt avtal, och ett system som bara tillåter en modell per adress kommer att kämpa emot din säljare hela hösten.

Var fakturaraderna ska komma ifrån

Här är kärnan. När arbetet på ett utkall är klart och någon trycker på bekräfta, skapar systemet fakturaraderna: en rad per utförd adress, prissatt efter sin pristyp, på kundens öppna fakturautkast för den månad då arbetet utfördes. Samma månads arbete samlas på ett utkast per kund (eller per adress, om kunden vill ha det så), så att kunden får en läsbar faktura i stället för fyrtio.

Lägg märke till vad som saknas: ingen skrev något. Kontorets jobb går från att mata in uppgifter till att granska: öppna utkastet, läs raderna, rätta det verkligheten kräver (ändra ett antal, lägg till en egen rad för bortforslingen, arkivera en rad som inte ska faktureras), lägg till en anteckning eller ett foto för kundens skull och skicka. Att bekräfta två gånger ställer inte till något, eftersom systemet minns vad det redan har skapat och bara lägger till det nya. Stopp som slutade som "kunde inte utföras" eller togs bort faktureras inte och blockerar inget.

Och eftersom raderna skapas vid varje bekräftelse i stället för vid månadsskiftet slutar faktureringen att vara en brant. Säsongens pappersarbete görs löpande, några minuter i taget, i stället för under en brutal vecka.

Vilket pris som hamnar på raden

Prisdiskussioner handlar oftast om spårbarhet, så det spelar roll i vilken ordning priset hämtas, och ordningen ska synas:

1. En prisregel på adressen vars schema eller period matchar utkallets planerade tid: helgpriset, priset utanför ordinarie tid. Raden får en markering som namnger regeln.
2. Adressens eget pris för arbetstypen.
3. Standardpriset för arbetstypen från inställningarna, för adresser utan eget pris.

Finns inget av dem skapas ingen rad (inga tysta nollor på kundens faktura), och stoppet väntar i stället på att faktureras i efterhand. När kunden frågar "varför blev det det här beloppet?" står svaret på raden, inte i någons minne av avtalet. Har avtalen en årlig uppräkning kan priserna höjas med en procentsats för alla adresser på en gång, och befintliga utkast påverkas inte: priset sätts när raden skapas.

Skyddsnäten: dubbletter, nollor och saknade priser

Skillnaden mellan ett faktureringssystem och en fakturagenerator är allt som systemet vägrar att göra i tysthet:

• Möjlig dubblett markeras när ett annat utkall har fakturerat samma arbete på adressen inom sex timmar, så att en människa kan avgöra om det var en avsiktlig andra körning.
• Noll med en förklaring när ett timdebiterat stopp saknar användbara tider: raden skapas med antal noll och en anteckning, synligt fel i stället för tyst borta, så att du rättar tiderna i stället för att förlora pengarna.
• En adress, en rad även när två rutter passerade samma fastighet på ett utkall. En timrad fakturerar summan av passagerna.
• Skickad betyder låst. En skickad faktura kan inte ändras i smyg. För att ändra den måste den uttryckligen tas tillbaka till utkast, och historiken visar vem som ändrade vad.

Fältanteckning: gå igenom förra säsongen och leta efter de två klassiska läckorna, åt båda hållen: arbete som gjordes men aldrig fakturerades (oftast adresser utan pris och glömda extrajobb) och arbete som fakturerades två gånger (oftast överlappande utkall). Den siffra som skämmer ut dig mest avgör vilket skyddsnät du ska kräva först.

Avräkning med underentreprenörer från samma underlag

Om underentreprenörer gör en del av jobbet har faktureringen två sidor: kundens faktura och underentreprenörens avräkning, och de måste stämma med varandra. Den rena lösningen prissätter varje utfört stopp en gång per led i kedjan: ägaren fakturerar kunden till sitt pris och avräknar underentreprenören till den avtalade kostnaden, båda skapade från samma utförda stopp. Raderna känner till varandra. Ändrar du den ena medan båda är utkast frågar systemet om ändringen ska följa med till den andra, och rader som inte längre stämmer överens flaggas.

Så slutar "kunden betalade för 40 besök men vi avräknade underentreprenören för 43" att vara en upptäckt i slutet av säsongen. Hela arbetsflödet, från att bjuda in underentreprenörer till att lämna över adresser, finns i guiden om underentreprenörer och på sidan om underentreprenörshantering.

Överlämningen till bokföringen

En faktura är inte klar förrän den finns i bokföringen. Leta efter en direkt koppling till ditt bokföringsprogram, och kontrollera att fel syns. SnowManager skickar i dag fakturor till e-conomic, Dinero, QuickBooks Online och QuickBooks Desktop. En faktura som bokföringsprogrammet avvisar hamnar i en felstatus som du ser, rättar och skickar igen, i stället för att försvinna. Utöver det behövs exporter för allt annat: timöversikter, månadsöversikter per underentreprenör och arkiverade rader, som CSV eller Excel. Använder ni ett bokföringsprogram som inte finns bland kopplingarna är det exporterna du ska titta på, så fråga leverantören konkret hur underlaget kommer över.

Regeln att hålla fast vid: ingenting skrivs in två gånger. Från fältet till utkast, från utkast till skickad, från skickad till bokföring, varje steg en överlämning och inte en avskrift. Mer om hur det fungerar i praktiken finns på sidan om fakturering.

En sak skiljer kommuner från entreprenörer: en kommun som sköter vinterväghållningen i egen regi har inga kunder att fakturera. Där döljer SnowManager faktureringsvyerna helt, se SnowManager för kommuner.

Frågor att ställa till leverantören

• Kan en adress ha olika pristyper för olika arbetstyper?
• Visa mig exakt när ett utfört utkall blir fakturarader. Vem tryckte på vad?
• Var kommer antalet på en timrad ifrån, och vad händer när tiderna saknas?
• Vad hindrar mig från att fakturera samma arbete två gånger?
• Hur fungerar delbetalningar per säsong, och vad händer med raderna per besök under ett säsongsavtal?
• Om jag höjer ett pris mitt i säsongen, vad händer med befintliga utkast? (Rätt svar: ingenting, raderna prissätts när de skapas.)
• Visa mig underentreprenörens avräkningsrad för samma utförda stopp som en kundrad.
• Vad hamnar i mitt bokföringsprogram, och vad händer när överföringen misslyckas?

Sammanfattning och nästa steg

Ett bra faktureringssystem för snöröjning märks knappt: det bevakar bekräftade utkall, skapar ärliga rader från registrerat arbete, vägrar att tyst dubblera eller nolla något, avräknar båda sidor av varje stopp från samma underlag och lämnar färdiga fakturor till bokföringen utan att någon skriver av dem. Ekonomiansvarig får tillbaka sin april, och kunden får fakturor som håller för granskning. Det är värt mer än någon enskild funktion, för det är ryktet som förnyar avtalen.

Faktureringen i SnowManager fungerar precis så eftersom den matas av allt som kommer före: planeringen av utkall, tiderna från GPS och dokumentationen från fältet. Se hela kedjan i Vilket system använder snöröjningsföretag?, eller boka en demo och ta med förra vinterns krångligaste fakturadiskussion.