avbryt
Viser resultater for 
Søk heller etter 
Mente du: 
Mine områder

Logg inn eller registrer en ny bruker

for å automatisk få tildelt relevante områder i Mine områder.

Kaj A Sortebech
CONTRIBUTOR ***

Retro-inkonsistens

av Kaj A Sortebech

Visma skriver og retro-funksjonaliteten:

 

"Men sannheten er at retro har betydelige fordeler for deg som bruker av Visma.net Payroll. Måten retro fungerer på er i tråd med gjeldende regelverk for innrapportering til a-melding. I hovedtrekk betyr det at kontantytelser skal følge kontantprinsippet og rapporteres i utbetalingsmåneden, mens naturalytelser, trekk og korreksjoner skal rapporteres i den måneden ytelsen gjelder.  Fordelen er at Payroll ordner dette selv, så lenge du er nøye med å angi korrekt dato for når en ytelse skal gjelde. Legger du f.eks. inn en firmabil i oktober som gjelder fra 1. september vil Payroll automatisk sende en retroaktiv a-melding for september i tillegg til den ordinære for oktober".

 

2 ansatte hadde dekket egne lisvforsikringer.  For den ene var det endret beløp i løpet av året (prisstigning), mens for den andre så hadde autogirobeløpet blir overskredet og stoppet opp. Gikk inn på ansattes faste transaksjonene for å endre grunnlaget for beskatning. Effekten av dette var at det ble generert korrigerte a-meldinger for tidligere perioder, uten at det ble laget nye samsvarende lønnskjøringer og dermed også regnskapsbunter. Dermed ble det inkonsistens mellom a-meldingene, lønnstransaksjoner og regnskapstransaksjoner selv om jeg egentlig oppnådde det som Visma beskriver ovenfor som korrekt innrapportering.

 

Det som Visma beskriver som fordelaktig, vil jeg beskrives som ukontrollerbar dysfunksjonalitet når man sitter der og skal forklare avvikene, korrigere/forklare avvikende betalinger til skattekontoret og få alt gjenspeilet i regnskapet.

 

Minimum så bør det genereres korrigerende lønnskjøringer, så det blir konsistens mellom a-meldingene og lønn (og dermed regnskapet).

 

Min egentlige løsning hvis jeg hadde forstått effekten, hadde vært å lage en variabel lønnsart hvor jeg ikke hadde brydd meg med det «politisk korrekte», men løst problemet på enkleste måte med en lønnskjøring i desember. For å bli sittende i timesvis for først å forstå problemet og så få kontroll på det, den situasjonen blir jeg ikke å komme opp i på ny. Glad dette var en lønnsklient med 4 ansatte og ikke de som vi ellers kjører lønn for i Visma Lønn. Skal bli lenge til de blir flyttet til Payroll om de blir det noen gang.

10 SVAR 10
Hanna Eid
VISMA

av Hanna Eid

Hei! 

Det er veldig beklagelig at dere opplever løsningen som problematisk når det gjelder håndteringen av retroer. 

Det er slik at Visma.net Payroll alltid følger kontantprinsippet. Det er en av grunnpilarene i løsningen. Hensikten med den er at systemet skal sørge for at alt blir rapportert inn riktig hele veien, og unngå at det gjøres feil. Feil på dette vil få konsekvenser ikke bare for virksomheten, men også for de ansatte med tanke på hvilke ytelser de har krav på hos NAV og andre offentlige instanser. 

Jeg ser at dette kan skape utfordringer for avstemmingen mot regnskap, men slik det er i dag er det ingen enkel måte å løse dette på. Det er i hovedsak fordi vi støtter filformater som brukes mot mange forskjellige regnskapssystemer. Disse filformatene støtter per i dag ikke å postere transaksjoner tilbake i tid. Å endre dette vil ikke bare kreve endringer hos oss, men også hos hver enkelte av mottaksystemene som støtter disse formatene. 

Når det er sagt så har vi noen tiltak på vei som vil kunne gjøre dette enklere: 

  • I det nye brukergrensesnittet på Visma.net Payroll kommer vi til å forbedre måten vi presenterer disse retroaktive transaksjonene. 
  • Vi kommer til å tilby et API for eksport av regnskapstransaksjoner. Dette vil gi mer fleksibilitet i hvordan man kan integrere mot et regnskapssystem for overføring av bokføringstall.

 

I mellomtiden tilbyr vi rapporter som skal hjelpe til med disse avstemningene. Blant annet har vi en rapport som viser avvik mellom innrapporterte tall og bokførte tall. Jeg vil anbefale å ta en kikk på brukertipset vi har liggende ute på dette. Dere finner det her: 

https://community.visma.com/t5/Brukertips-i-Visma-net-Payroll/Avstemming-av-a-melding-mot-regnskap/t... 

Ellers vil jeg også på generell basis anbefale å lese denne artikkelen som sier noe om hva retro transaksjoner er og hvorfor man får disse: 

https://community.visma.com/t5/Brukertips-i-Visma-net-Payroll/Hva-er-retro-og-hvorfor-far-jeg-det/ta... 

 

Mvh

Hanna

Nils Fossum
GURU *

av Nils Fossum

Takk for raskt kommentar og tips til nyttige artikler i hjelpefilen Hanna! Dagens løsning med at alt posteres ifm. inneværende periode er for mange eneste brukbare løsning, da regnskapsperioder ofte lukkes ifm. rapportering, avstemming og revisjon. Det er godt å høre at dere har tiltak på vei som vil gjøre dette med retroaktive a-meldinger mer brukervennlig for de som kjører lønn og jobber med avstemming/revisjon av lønnsområdet. Skattemyndighetene tenkte nok ikke så mye på praktisk gjennomføring da de laget veiledningen for a-meldingen dessverre. Etterlevelsen av alle detaljer rundt periodisering har nok derfor blitt litt deretter. Det har stort sett gått bra til nå og skjønner at man via sine datoinnlegginger i Payroll også kan velge å ta mer hensyn til det praktiske enn det teoretisk riktige, og det synes jeg er bra. Antall selskaper som tar i bruk Payroll vil jeg tro er sterkt økende om dagen, selv om jeg har inntrykk av at store deler av regnskapskontorbransjen velger å fortsette med Huldt & Lillevik og Visma Lønn i hvert fall en stund til. Alle tiltak som gjøres nå for å informere godt om denne litt uvante tekniske løsningen i Payroll, vil nok derfor være en god investering for fremtiden.

 

Mvh

Nils

Nils Fossum
GURU *

av Nils Fossum

Drar i gang Payroll for et par klienter nå i disse dager og kjenner jeg får vondt i magen av å lese denne meldingstråden. Vi må ha kontroll på hva som skjer og alt må være både reviderbart (audit trail) og avstembart. Perioder låses så den som kjører lønnen må ha kontroll på når ting blir innrapportert. Vi bruker mye tid på de terminvise avstemmingene på lønnsområdet, så vi må være sikre på at de holder seg riktige. En avstemming av lønnsområdet er en avstemming av finansregnskapet mot det som er innberettet! Da sier det seg selv at man må ha samsvar begge steder for å kunne foreta en avstemming. Kjenner absolutt ikke Payroll enda da jeg bare har brukt noen få timer på å klargjøre for 2021 foreløpig. Men en ting jeg allerede har reagert på er dette med håndteringen av innskuddspensjon og refusjoner fra NAV. Er vant med å ha tre konti i regnskapet for begge disse forholdene. To konti brukes for henholdsvis bankbilaget ifm. utbetalingen fra NAV og kostnadskonto for pensjonspremien. De fire andre kontiene er konto/motkonto for lønnsarten for refusjoner fra NAV og og de AGA-pliktige betalingene til pensjonsordningen. Skjønner at jeg kan få til en slik løsning i Payroll også men at det ikke er tenkt behandlet slik i standard oppsett var litt urovekkende synes jeg. 

Kaj Arne Sortebech1
CONTRIBUTOR ***

av Kaj Arne Sortebech1

Så lenge som at du ikke setter datoer slik at du får tilbakevirkende effekt på tidligere terminer, så går det rimelig bra, men rapporter for avstemming og lignende er vanskelig å få gode. Men av og til med utlegg og forskudd så har jeg klart å trigge Retro-funksjonen uten at jeg neste klarer å få det bort. Som sagt, så lenge som at man ikke er "for smart" med å legge inn virkelige datoer, så fungerer det best.

 

Bruker selv PowerPivot i forhold til Visma Lønn og Business, noe som gir god kontroll på dataene og avstemminger/rapporteringer. Dette er svært vanskelig med Payroll, Payroll er som å titte inn i et nøkkelhull og forstå hva som skjer.

JensGuddal
CONTRIBUTOR ***

av JensGuddal

Jeg stiller meg bak Kaj her. Ser fordelen og prinsippet med retroaktive endringer, men med rundt 100 ansatte i systemet, hvor de aller fleste arbeider på timelønn, er på reis og feks reiseregninger med diett og utlegg blir sendt inn til godkjenning gjerne i etterkant av en rotasjon, og dermed tilbake til en senere periode. Dette skaper hodebry av dimensjoner når det kommer til avstemming av aga og fst. Jeg ser så absolutt hensikten, og det er enkelt å registrere og innrapportere hendelser tilbake i tid, men det kommer ikke frem i regnskapsbilagene som blir sendt fra payroll til financials - noe som fører til mye tidsbruk på avstemming og inkonsistens.

Kaj Arne Sortebech1
CONTRIBUTOR ***

av Kaj Arne Sortebech1

Det er dessverre noen ansvarlige i Visma som ikke forstår spesielt mye når det gjelder f.eks sammenhengen mellom lønn og regnskap inkl rapportering, avstemming og kontroll. Mulig Visma er blitt for stor og mistet kontakt og respekt ovenfor sine kunder?

Hanna Eid
VISMA

av Hanna Eid

Hei Kaj,

Det er veldig beklagelig å høre at du har brukt mye tid på dette. 

Årsaken til at det er gjort på denne måten er fordi kontantprinsippet styrer hvilke perioder en korreksjon skal rapporteres på: https://www.skatteetaten.no/bedrift-og-organisasjon/arbeidsgiver/a-meldingen/veiledning/lonn-og-ytel...

Hensikten med korreksjonsprosessen i Payroll er at dette skal bli korrekt uten at du skal måtte ta stilling til hvilke perioder korreksjonene skal rapporteres på. Å korrigere på riktig periode vil bli mer og mer viktig etterhvert som flere aktører henter ut data fra a-meldingen. Blant annet brukes dette til beregning av sykepenger, lån og etterhvert pensjon hos pensjonstilbyderne. 

Grunnen til at det ikke blir generert lønnskjøringer for hver periode, er for å unngå at du skal måtte gå gjennom en hel lønnsprosess for hver periode som skal korrigeres. 

I noen tilfeller vil dette kunne skape utfordringer med avstemming av tall mot regnskapet. Det kan være at vi kan se på om vi for eksempel kan presentere regnskapstallene på en annen måte i Payroll for å gjøre det enklere å få en oversikt. Jeg skal ta det med videre som et innspill til fremtidig utvikling.

 

Mvh

Hanna

Kaj A Sortebech
CONTRIBUTOR ***

av Kaj A Sortebech

Det er ikke holdbart at man ikke oppnår konsistens mellom a-meldinger, lønnskjøringer, regnskapskjøringer, bankkonter og skattekontoret. Når man endrer i a-meldinger, så endrer man hva som skulle ha vært betalt inn av arbeidsgiveravgift og eventuelt skattetrekk. F.eks økt eller redusert skattetrekk må endres i regnskapet og det må eventuelt betales inn med korrekt kidkode så det kommer inn på rett oppgave. Hvordan vet skattekontoret at det er korrekt at det skal betales tilbake?

 

Jeg hold på å sette overskriften til retro-galskap, men unnlot det, men siden dere sliter med å forstå de praktiske konsekvensene, så nevner jeg det allikevel. Jeg kommer ikke til å overføre flere lønnsklienter til dette systemet før det er blitt mer brukervennlig i den forstand at man forstår og ser hva som foregår og får konsistens i dataene og betalingene. Det er faktisk regelrett galskap slik det fungerer i dag.

 

Hanna Eid
VISMA

av Hanna Eid

Hei! 

Takk for samtalen tidligere i dag. Jeg har notert meg de tilbakemeldingeen du kom med, og kommer til å ta det med videre for å se på hvordan vi presenterer dette med retroer i systemet.

 

Ha en fin dag videre!

 

Mvh

Hanna

Kaj A Sortebech
CONTRIBUTOR ***

av Kaj A Sortebech

Individuell livsforsikring som ble trukket fra bankkonto til bedriften hadde blitt stoppet for en ansatt, mens det fortsatt lå inne som fast transaksjon for beregning av skatt og arbeidsgiveravgift. Ved å sette inn sluttdato tilbake til når trekket hadde stoppet opp, så ble det kjørt en omberegning av tidligere oppgaver til AltInn i Payroll uten å vise hva som ble endret eller mulighet til å stoppe det.

 

Det finnes ingen spor i utskrifter/rapporter i AltInn hva som er gjort av endringer og heller ikke produsert endringsbunt til regnskap.

 

Heldigvis har jeg tatt ut gamle og nye rapporter fra AltInn som jeg kan se endringen som er gjort. Ellers ville dette vært umulig å spore og forklare til de som fører regnskap og skal avstemme skattetrekk og arbeidsgiveravgift.

 

Antar at hele hendelsen har medført 2-3 dagers merarbeid til sammen for de som jobber med lønn, regnskap og skattemyndigheten inkl avvik i innbetaling av skatt og arbeidsgiveravgift.