Overview
With this integration you will connect Simployer One to your Agda PS account via SFTP and can then do the following:
Scheduled or manual sync of employee data such as personal information, employment data, compensation data and more from Simployer to Agda PS.
Available in: Sweden
Agda PS requirements
SFTP server access
You must request a dedicated SFTP account from Agda PS support. Agda PS will provide the credentials to enable Simployer One to deliver the XML file(s).
Agda import job setup
Agda PS must configure an import job to automatically process these XML files from your SFTP file area.
Note: When configuring the integration, you can choose to send the files to either folder Test\Importfiler or Prod\Importfiler on your Agda PS SFTP area. You can use this during the setup process together with Agda.
Note: There may be setup and ongoing service fees from Agda PS for file processing.
How Agda PS File Transfer Works
When your integration runs, Simployer One automatically creates employee files in Agda PS XML Person Export format and sends them to your Agda PS SFTP import area.
Multiple Organizations
If you have multiple organizations in Simployer One, you'll get one file for each organization. This makes it easier to import data into Agda PS separately and for Agda PS to understand which organization should go to which Adga PS company.
File Names
Files are named to help you identify them:
[Organization ID]-[Organization Name]-employees-[Date and Time].xml
Example: 1-Acme_Corp-employees-20250103-143022.xml
File Location
Files are delivered to the folder you chose during setup.
Set up in Simployer
The integration is activated from Settings → Integrations → Select payroll system → Add integration
In the API Integrations section, select Agda PS
Click Next to start the configuration wizard
Enter all the details needed for the connection
Optionally: set up a specific scope (which employees to include in the sync) and/or a scheduled sync from Simployer to Agda PS
Settings
You can choose how the integration sync for employees is executed. The options available are as follows:
Manual sync
The data is manually synced to Agda PS by the user
This can be valuable if you have the scheduled sync turned off and want to control when data is synced to Agda PS. Either during the implementation phase or during times when an update is not wanted due to process and payroll timing
Manual syncs can be performed even when a scheduled sync is configured. This may be necessary if there have been a significant number of changes in Simployer after a scheduled sync has been executed
Scheduled sync
The sync runs on a schedule that you can define
Options include the day(s) of the week and the time of day for the sync to be executed
Note : Currently the sync is queued and it starts shortly after 06:00 CET.
Scope
The edit scope settings allows for more granularity on what employee will be part of the automatic or manually triggered employee export. This is useful if you know that not all of the employees should be exported to Agda PS.
The scope selection follows the standard scope selection that exists in Simployer.
Employee data
Overview
Employee data is synchronized from Simployer to Agda PS. This means that if data is updated in Adgda PS on "data fields" and then the sync from Simployer is done the data in Agda PS will be overwritten.
When the sync is executed it will compare the data in Simployer for the "data fields" to see if there is a difference between the values for those fields in Agda PS. If there is no change, the user will not be updated. If there is a change present, the data will be updated.
Some fields are currently hardcoded, see below for more information.
Data fields
Personal Information
Simployer One | Agda PS XML Field | Notes |
Person.employeeNumber | ANST_NR | Required - Long integer (1-999999999999) |
Person.nationalIdList[0].nationalId | PERSNR | Required - Swedish SSN format |
Person.firstName | FORNAMN | Required |
Person.lastName | EFTERNAMN | Required |
Person.gender | KON | MALE→"M", FEMALE→"K", other→"" |
Person.email | EMAILADRESS |
|
Person.birthdate | FODELSEDATUM | yyyy-MM-dd format |
Person.nationalIdList[0].country | MEDBORGARSKAP | From nationalId, not address |
Employee.organizationId | FTG_NR | If organizationId missing, hard-coded to “1” |
Note: FTG_NR + ANST_NR is what makes an employee unique in Agda PS.
Address Information
Simployer One | Agda PS XML Field | Notes |
Person.address.streetAddress1 | ADRESS | Home address only |
Person.address.postalCode | POSTNR |
|
Person.address.city | ORT |
|
Person.address.country | LAND |
|
Person.phoneNumber | TELEFON | Mobile address entry |
(hard-coded) | ADRESSTYP | "Hemadress" for address, "Mobiltelefon" for phone |
(hard-coded) | GALLANDE | true for home address, false for mobile |
Section omitted when: No address data AND no phone number present
Position Information
Simployer One | Agda PS XML Field | Notes |
Employee.jobTitle | BEFATTNING | Section omitted if empty or null |
(hard-coded) | BEFATTNINGSSTATUS | Hard-coded: "H" |
Employment Information
Simployer One | Agda PS XML Field | Notes |
Employee.hireDate | ANSTALLNINGSDATUM | Required for active employees |
Employment.endDate | AVGANGSDATUM | Only if person inactive OR no ongoing employment |
Employment.employmentType | ANSTALLNINGSFORM | permanent_employment→"Tillsvidareanställning", probation_employment→"Provanställning", hourly_employment→"Timanställning", fixed_employment→"Vikariat", consultant→"Konsult" |
Employment.startDate | TILLTRADE | Per employment period |
Employment.endDate | TILLTRADETOM | Per employment period |
Employee Inclusion Logic:
Employees with ongoing employment (no end date) are included
Employees with future hire dates (new hires being prepared) are included
Terminated employees within 30-day grace period are included
Terminated employees beyond 30-day grace period are filtered out
Working Time
Simployer One | Agda PS XML Field | Notes |
Employment.rate | SYSSELSATTNINGSGRAD | All employments with rate > 0 included, sorted by start date. Monthly salaries are automatically pro-rated based on the active employment rate at compensation's effective date. |
Employment.startDate | FRAN | ISO date format (yyyy-MM-dd) |
Employment.endDate | TILL | ISO date format (yyyy-MM-dd). Empty if no end date. |
Section omitted when: No employments OR all employments have rate = 0 or null
Bank Account
Simployer One | Agda PS XML Field | Notes |
Person.bankAccount.clearing | CLEARINGNUMMER | First 4 digits of clearing number |
Person.bankAccount.clearing | CHECKSIFFRA | Remaining digits after first 4 (if clearing > 4 digits) |
Person.bankAccount.accountNumber | BANKKONTONUMMER |
|
Person.bankAccount.iban | IBAN |
|
Person.bankAccount.bic | BIC |
|
(hard-coded) | UTBETALNINGSTYP | Hard-coded: "Löneutbetalning" |
(hard-coded) | UTBETALNINGSSATT | Hard-coded: "Bankkonto" |
Section omitted when: No bank account data
Clearing Number Logic: If clearing number has more than 4 digits, the first 4 go to CLEARINGNUMMER and the remaining digits go to CHECKSIFFRA.
Organization
Simployer One | Agda PS XML Field | Notes |
Office.name | TJANSTESTALLE | Service location/office name |
Group.groupName | AVDELNING | Department name |
Manager name | ARBETSLEDARE | Manager's full name (firstName + lastName) |
Section omitted when: No office, department, or manager data present
Accounting Dimensions
Simployer One | Agda PS XML Field | Notes |
CostCenter.costCenterCode | PKONTERING2 (value) | Cost center code as element value |
CostCenter.costCenterName | PKONTERING2 @KORTNAMN | Cost center name as attribute |
(hard-coded) | PKONTERING2 @NAMN | Hard-coded: "Kostnadsställe" |
Custom field: "DS-kod" | PKONTERING3 (value) | Custom field value from employee |
(hard-coded) | PKONTERING3 @NAMN | Hard-coded: "DS" |
Section omitted when: No cost center AND no custom field "ds" present
Example XML:
<Konteringar> <Kontering> <PKONTERING2 NAMN="Kostnadsställe" KORTNAMN="TestCC01">CC01</PKONTERING2> <PKONTERING3 NAMN="DS">123</PKONTERING3> </Kontering> </Konteringar>
XML
Next of Kin (Children)
Simployer One | Agda PS XML Field | Notes |
Child.name | NARSTAENDENAMN | Child's full name |
Child.birthDate | NARSTAENDEFODELSEDAG | Birth date in yyyy-MM-dd format |
(hard-coded) | NARSTAENDENOTERING | Hard-coded: "Barn" |
(hard-coded) | NARSTAENDEVISAEJ | Hard-coded: false |
Section omitted when: No children registered for employee
Salary Components
Simployer One | Agda PS XML Field | Notes |
Payroll.payoutPeriod / AdditionalCompensation.salaryCode | LONEART | MONTHLY→"70", HOURLY→"10", or custom salary code (1-999) for additional compensations |
Compensation.compensationAmount / AdditionalCompensation.amount | BELOPP | For MONTHLY salary or additional compensations. See pro-rating rules below. |
Compensation.compensationAmount | PRIS | For HOURLY salary (price). Never pro-rated. |
Payroll.payrollEffectiveDate / AdditionalCompensation.effectiveDate | DATUM_IN | Start date (as XML attribute) |
(calculated) | DATUM_UT | End date: calculated (day before next payroll) for standard salaries, or explicit end date for additional compensations |
(type-specific) | FASTAARTER_TYP | "A" for MONTHLY/additional compensations, "P" for HOURLY |
Section omitted when: No compensation/payroll data OR no supported salary types
Pro-Rating Rules
? What gets pro-rated:
✅ MONTHLY salaries (LONEART 70) are automatically pro-rated by the employment rate active at the salary's effective date
❌ HOURLY salaries (LONEART 10) are never pro-rated (the rate per hour stays the same)
❌ Additional compensations are never pro-rated (fixed amounts as entered in Simployer One)
? How pro-rating works:
The integration finds the employment record that is active on the salary's effective date
The salary amount is multiplied by the employment rate:
amount × (rate / 100)Example: 15,000 SEK salary at 50% employment = 7,500 SEK sent to Agda
? Important for part-time employees:
When an employee's employment rate changes (e.g., from 100% to 50%), you must create a new compensation entry in Simployer One with the same effective date as the rate change
This ensures Agda receives the correctly pro-rated amount from the date of the change
The integration will issue a validation warning if it detects a rate change without a matching compensation entry
Example Scenario:
2025-07-01: Employment 100%, Salary 10,000 SEK → Agda receives 10,000 SEK 2025-08-01: Employment changes to 50%, NEW Salary 15,000 SEK created → Agda receives 7,500 SEK
Salary Processing Logic
Standard Compensations: Payrolls are separated by type (MONTHLY vs HOURLY), sorted by effective date, with calculated end dates
Additional Compensations: Mapped independently with their own custom salary codes (LONEART 1-999) and explicit start/end dates from Simployer One
Additional compensations require valid salary code (1-999) - invalid/missing codes are skipped and reported
These run in parallel with standard monthly/hourly salaries
Use
<BELOPP>element with type "A" (like monthly salaries)Sourced from
AdditionalCompensationlist in Alexis
MONTHLY creates
<BELOPP>elements with type "A"HOURLY creates
<PRIS>elements with type "P"
Example XML Output
<FastaArter> <!-- Monthly salary at 100% employment rate --> <FastArt DATUM_IN="2025-07-01"> <LONEART>70</LONEART> <BELOPP>10000</BELOPP> <!-- 10,000 × 100% = 10,000 --> <FASTAARTER_TYP>A</FASTAARTER_TYP> <DATUM_UT>2025-07-31</DATUM_UT> </FastArt> <!-- Monthly salary at 50% employment rate --> <FastArt DATUM_IN="2025-08-01"> <LONEART>70</LONEART> <BELOPP>7500</BELOPP> <!-- 15,000 × 50% = 7,500 --> <FASTAARTER_TYP>A</FASTAARTER_TYP> <DATUM_UT></DATUM_UT> </FastArt> <!-- Hourly salary (NOT pro-rated) --> <FastArt DATUM_IN="2025-09-01"> <LONEART>10</LONEART> <PRIS>100</PRIS> <!-- Always 100 SEK/hour regardless of rate --> <FASTAARTER_TYP>P</FASTAARTER_TYP> <DATUM_UT></DATUM_UT> </FastArt> <!-- Additional compensation (NOT pro-rated) --> <FastArt DATUM_IN="2025-10-01"> <LONEART>990</LONEART> <BELOPP>500</BELOPP> <!-- Fixed 500 SEK regardless of rate --> <FASTAARTER_TYP>A</FASTAARTER_TYP> <DATUM_UT>2025-12-31</DATUM_UT> </FastArt> </FastaArter>
XML
Vacation Entitlement
Simployer One | Agda PS XML Field | Notes |
Custom field with label: Semesterrätt | SEMESTERRATT | Please note this will overwrite the data field in Agda without creating a history post, don't use this field if this is not acceptable. |
Limitations
Absence data is not synchronized.
Only employee information is transferred—no leave, absence, or time reporting data.
No real-time updates; the integration operates via batch file transfer up to once per day or on manual trigger.
Only employees with valid Swedish personal numbers and employee numbers are processed.
Recently terminated employees are included only for 30 days after end date.
Troubleshooting & questions
For technical questions around XML output from Simployer One, contact the Simployer support.
For inquiries about setting up Agda PS import jobs and SFTP access, contact Agda PS support.
Example XML output
If needed, you can request a sample of the XML file output from the Simployer Integration Team for review.