Optional. Set it to file this receipt against a card purchase returned by card-transactions. Only settable when the entry is created; an update may repeat the key the entry already carries, but cannot add, change or remove the link. The purchase must be one of the caller's own open, confirmed purchases, i.e. one that card-transactions returned. A key naming anything else is rejected. When the purchase has a company-card, file the entry with that card and with the amount the card was charged: copy billing-amount into amount and billing-currency-type into currency-type. The purchase amount and currency are not accepted for a purchase made in another currency. VAT follows the entry's own country-code, which normally comes from the purchase. When it differs from the company's country, send vat as 0: no VAT may be claimed on a receipt from another country, and an entry that carries any is rejected with a conflict. Unlike the company card and the amount, the country is not checked against the purchase, so a receipt that genuinely belongs to another country than the card issuer reports can be filed as such. Stable identifier of the card purchase. Pass it back as the card-transaction reference on expense-entry-writable to file a receipt against this purchase. The last four digits of the card, with the preceding digits masked. Enough to recognise a card that is not registered as a company card in Kleer; use company-card below when the purchase matched a registered card. The VAT the card issuer reports for the purchase. File it as the entry's vat only when the entry is filed with the company's own country-code: no VAT may be claimed on a receipt from another country, and such an entry is rejected with a conflict however much this field reports. The rule is evaluated against the country-code on the entry, not the one below, so it is the entry's own country that decides. See the country-code documentation below. What the card was actually charged, in billing-currency-type. This is the pair to file a receipt with when the purchase has a company-card: the entry's amount and currency-type must equal billing-amount and billing-currency-type, not the purchase amount and currency above. Filing the purchase amount for a purchase made in another currency is rejected as a conflict, with a message about changing the amount. Where the card issuer says the purchase was made, and the value to copy onto the entry unless the receipt itself says otherwise. It is a suggestion, not a constraint: the entry may be filed with a different country-code and is not rejected for disagreeing with this one, the same way the form in Kleer lets the country be changed and prefers the country of a previous receipt from the same merchant over this value. What it does decide is VAT. The entry's own country-code is compared with the company's, and an entry from another country may not carry VAT. So copying this value onto the entry means vat must be 0 whenever it differs from the company's country. True while the purchase is a reservation we have not registered an authorisation for: an expense filed against it cannot be bundled into an expense report yet. False once the authorisation is registered, including for purchases that started as a reservation. Computed from our own reservation and authorisation records, while the amounts above come from the card issuer. The two can disagree - the issuer may have authorised a purchase whose authorisation never reached us - in which case this is true next to amounts that are already final. That is deliberate: it answers whether the purchase can be filed and bundled, which is the promise a caller acts on, not what the issuer currently reports. Mileage entry type. One of: "Single" (a single trip, with start/end descriptions and optional coordinates) or "Batch" (an aggregated driving-logbook entry, where start/end descriptions may be absent). Tax-free reimbursement amount for the trip, in cents. Taxable reimbursement amount for the trip, in cents. One-way travel distance, in kilometres. Total travel distance in kilometres; equals distance-one-way-km, doubled when round-trip is true. Taxable benefit (förmån) for provided meals, in cents. A user's registered car (the car-id returned in expense-mileage). Requires payroll read access. The car's registration number. Absent if none is registered. Skatteverket model code (Modellkod) for benefit cars; format YY+model+nr (e.g. 24ABC123). Absent if not set. This element id deprecated. As a single expense can contain entries with different company-cards. See expense-entry-readable for its actual company-card value. Value here is unspecified if multiple company-cards in expense. The company's active company cards. Requires read access to company cards. Main currency type for the company, ie the accounting currency type. Vat code used for this transaction. Vat code used for this transaction, or null if none. If at least one transaction in the voucher has this element, all transactions will be vat coded according to the given definition. If no transactions have this element, vat codes will be assigned automatically based on account number. Optional dimension information for this transaction. Usage of project-element is deprecated, please use dimensions instead. Optional currency information for this transaction. One of the elements should be used. Currency that amount on transaction is specified in. The actual accounting amount will then be automatically determined using the exchange rate on the voucher's date. Explicit currency amount information for this transaction. Amount on transaction is implicitely assumed to be in the accounting currency. The serie that this voucher belongs to. The voucher's number in its given serie. Two vouchers in the same serie can not have the same number within the same accounting year. The description of the voucher The voucher's transaction date The transactions associated with this voucher. The account number for this transaction. Vat code used for this transaction. The internal identification used for this transaction The accounting amount for this transaction. The set of references associated with this transaction, always at least one. On a reference, further detailed information will be found, such as currency amount and any dimension entries. The type of this reference, e.g. where does this reference point? No specific reference, the transaction itself is the reference. This is the default case. The internal identification used for this transaction reference The accounting amount for this reference. The sum of all reference amounts is guranteed to be equal to the transaction's amount. The employee's comp time (flex/overtime) balance in hours, as of now. Negative when the employee owes hours. The date from which the tax percentage is valid. Required when tax-percentage is set. If omitted, defaults to January 1st of the current year. The date until which the tax percentage is valid. Required when tax-percentage is set. If omitted, defaults to December 31st of the current year. The date from which the specified monthly-salary is valid from. If omitted, default start date is start of current month. The date from which the specified hourly-salary is valid from. If omitted, default start date is start of current month. Sets the manager of this payroll user. Skip to leave the current manager as is. The id must reference an existing user in this company; an omitted, null or zero id is rejected. Use remove-manager-user to remove the current manager. Set to true to remove the current manager. Mutually exclusive with manager-user. Setting this element to true will automatically fetch an EDI-recipient for the given client and apply it if its identities matches strictly. If multiple recipients were found, no EDI-recipient will be set. Optional template to use as default when creating new client invoices with the client. When reading, this value is always set, where "null" means "use a reasonable default template". When writing, omitting this value will set it to "null" when creating, and leave it unchanged with updating. Optional approver to use as default when creating new client invoices with the client. When writing, omitting this value will set it to "none" when creating, and leave it unchanged with updating. When updating, set to null to explicitely clear any previously set value. Omitting this element will leave dimension-entries unchanged when updating Omitting this element will leave client-brokers unchanged when updating Value, if set, must be unique. Value, if set, must be unique within its dimension The dimension entry denoting this user. In other words, to create a dimension reference to this user, use this entry. Non-writable The last date, if any, that this invoice had a payment registered. Unique identifier for this row, read only value. Can be safely ignored when creating or updating client invoices. Unique identifier for reinvocing Id of the supplier invoice the reinvoicing is related to Id of the expense entry the reinvoicing is related to The amount in the invoice's currency that this payment represents. If the invoice's currency is the same as the company's accounting currency, this amount and accounting amount must always be equal. The accounting amount that this payment represents. If the invoice's currency is the same as the company's accounting currency, thus amount and invoice amount must be equal. Used when updating an existing revenue. Provide a <revenue-create> as when creating, together with a message with the reason for this update. If this revenue represents a credit for a prior created revenue, it must be referenced here. Negative revenues can not be created without referencing a debit. A unique identifier for this revenue. If given, the exact accounting amounts that should be used. If not given, final values will be determined using the exchange rate for the given currency on the transaction date. If not set, transaction date will be used. At least one file must be given, to use as basis for the accounting. A unique identifier for this revenue. The bank account that should be used as debtor for this supplier invoice. If none is given, a suitable bank account will automatically be chosen. This is an optional field only relevant if payments are performed from different bank accounts. If unsure, please leave empty. Select bank account associated with the given bankgiro. Select bank account with the given identifier. Vat code used for this account. If omitted, default vat code from account will be used. If null this account will not have vat code. Unique identifier for this account, read only value. Can be safely ignored when creating or updating supplier invoices. Optional when creating/updating. Default value will be used if not set Deprecated and no longer used Optional when creating/updating. Default value will be used if not set Vat percentage used for domestic sales using this product. Optional when creating/updating. Default value will be used if not set Deprecated, se will still be used to set account-nr, if it is not set. For backwards compatibility. When reading all elements will have value of account-nr. Optional when creating/updating. Default values will be used if not set. This field is deprecated and is no longer used. When creating or updating an agreement, this field is ignored. When reading an agreement, its value will always be identical to start-invoice-date. Optional when creating/updating. Empty value will be used if not set Set when reading agreements. Ignored when creating/updating Set when reading agreements. Ignored when creating/updating If activity id is absent, it is the users internal hourly cost for all unspecified activities If activity id is absent, it is the users internal hourly cost for all unspecified activities If price is absent, use activity default price Can be used to approve or deny the invoice, with optional comment. The type of approval can either be "APPROVAL" "DENIAL" or "TIMEOUT". The key (UUID) of the user who last updated the project. Non-writable. The date and time when the project was last updated. Non-writable. True when this project is a group project (koncernprojekt). A group project is replicated into the subsidiary companies that its members take part from, and the company must have the group project setting active. True when the group self-billing flow is enabled for this project. It is a modifier on a group project: it can only be turned on for a project that is, or is becoming, a group project, on a company that has the setting enabled. It is not the group internal invoice price, which is read and written through group-internal-price. True when this project is the replicated copy held by a subsidiary company. Such a copy is maintained from its master project and is read-only: attempts to change it through this API — updating the project, its users or its activities, and opening or closing it — are rejected. The exception is the subsidiary's own client-invoice prices (client-project prices), which belong to the copy and can still be set. Saving the master project overwrites the fields it mirrors, among them name, number, comment, currency, budget amount, opening and closing date, the member list and internal-invoicing-enabled. Fields outside that set, budget hours among them, are copied once when the copy is created and are not maintained afterwards. Can only be set when creating new project Optional client to use as client instead of "normal" client when creating new client invoices from the project. Omitting this value will set it to default when creating, and leave it unchanged when updating. Setting to null explicitely clears the value. Can only be set when creating new project Can only be set when creating new project Replaces the project's activities. Not allowed for companies with Project V2, where the project's activities are maintained through the activities endpoint instead. Replaces the project's members. For companies with Project V2 this only applies when creating a project: an update leaves the members unchanged, and they are maintained through the users endpoint instead. A member cannot carry activities for companies with Project V2, neither when creating nor when updating. Will not set status of project to closed, doing so is another operation. Omitting this element will leave dimension-entries unchanged when updating Makes the project a group project (koncernprojekt), which replicates it into the subsidiary companies its members take part from. Requires the company to have group projects active, and cannot be combined with fixed-price. Absent leaves the project as it is. Send it only when the value should change: sending false on a project that has already been replicated is rejected, because the copies the subsidiaries hold would stop being updated and nothing resyncs them afterwards. Replication needs a member taking part from another company in the group. Setting this alone leaves the project without subsidiary copies, and only activities whose base activity is a group activity are replicated. Enables the group self-billing flow for this project. It can only be turned on together with, or on, a group project, and only for a company that has the setting enabled, and it must be turned off before the project stops being a group project. Absent leaves the project as it is. This is not the group internal invoice price, which is read and written through group-internal-price. The company this member takes part from. Absent leaves an existing member as it is and places a new one in the project own company, which is the only company a member can take part from on a project that is not a group project. On a group project the set of subsidiary companies the project is replicated to is derived from the origin companies of its members, so a member taking part from another company in the group is what makes replication happen. Setting group-project without any such member leaves the project without subsidiary copies. The company must be one the project company shares a group with, and the user must have an active membership in it. This is checked when the member is added or the origin company changes, not on a member that is already taking part from it. Project leaders carry no origin company here: one supplied through this API always takes part from the project own company, and one taking part from another company is reported without that origin. One of Client, Supplier, Internal or SalaryBasis. Note that Internal is the project's own internal price. It is NOT the group's internal invoice price used when a master company invoices its subsidiaries for work on a group project — that price is per subsidiary and is read and written through group-internal-price. The group's internal invoice price for one subsidiary company, effective from valid-from. This is what the subsidiary invoices the master for work on a group project. It is a per-subsidiary OVERRIDE, not a separate kind of price. Where no override exists for a subsidiary, that same invoiced price comes from the master activity's own price of type "Internal" if one is set, and from its "Client" price otherwise. So setting type=Internal on client-project-activity-price does affect what subsidiaries are invoiced — for every subsidiary that has no override here. Setting it does not change what a subsidiary with an override is invoiced, and reading it does not tell you the overridden value. The group's per-subsidiary internal invoice prices for this activity, for every subsidiary currently in the project, including historical and future-dated rows. A stored price whose subsidiary has since left the project is not reported, because the company it belongs to can no longer be named in the response. Only populated when reading a single project (GET /client-project/{clientProjectId}) that is the master project of a group project in a company with cross-company projects active, and only for a caller with project read access; omitted from list responses and for all other projects. Note the consequence of that last condition: absence of this element means "not visible to you" as well as "none set", so do not read an empty result as proof that no internal invoice price exists. The company this member takes part from. Absent leaves an existing member as it is and places a new one in the project own company, which is the only company a member can take part from on a project that is not a group project. On a group project the set of subsidiary companies the project is replicated to is derived from the origin companies of its members, so a member taking part from another company in the group is what makes replication happen. Setting group-project without any such member leaves the project without subsidiary copies. The company must be one the project company shares a group with, and the user must have an active membership in it. This is checked when the member is added or the origin company changes, not on a member that is already taking part from it. Project leaders carry no origin company here: one supplied through this API always takes part from the project own company, and one taking part from another company is reported without that origin. True when this project is a group project (koncernprojekt). A group project is replicated into the subsidiary companies that its members take part from, and the company must have the group project setting active. True when the group self-billing flow is enabled for this project. It is a modifier on a group project: it can only be turned on for a project that is, or is becoming, a group project, on a company that has the setting enabled. It is not the group internal invoice price, which is read and written through group-internal-price. True when this project is the replicated copy held by a subsidiary company. Such a copy is maintained from its master project and is read-only: attempts to change it through this API — updating the project, its users or its activities, and opening or closing it — are rejected. The exception is the subsidiary's own client-invoice prices (client-project prices), which belong to the copy and can still be set. Saving the master project overwrites the fields it mirrors, among them name, number, comment, currency, budget amount, opening and closing date, the member list and internal-invoicing-enabled. Fields outside that set, budget hours among them, are copied once when the copy is created and are not maintained afterwards. The company this member takes part from. Absent leaves an existing member as it is and places a new one in the project own company. On a group project this is what decides which subsidiaries the project is replicated to. The company must be one the project company shares a group with, and the user must have an active membership in it; this is checked when the member is added or the origin company changes, not on a member that is already taking part from it. Sending a different origin-company for a user who already takes part moves that membership. One of Client, Supplier, Internal or SalaryBasis. Note that Internal sets the project's own internal price. It does NOT set the group's internal invoice price used when a master company invoices its subsidiaries for work on a group project — use activity-group-internal-price for that. One of Client, Supplier, Internal or SalaryBasis. As for activity-price, Internal is the project's own internal price and not the group's internal invoice price. The group's per-subsidiary internal invoice prices for one project activity, identified by its activity key. May only be sent by the master company for the master project of a group project in a company with cross-company projects active; any other caller is rejected. By default only the subsidiaries named in the payload are touched, and nothing is deleted. Activities not listed are left untouched either way. Set replace-all="true" to make the payload the AUTHORITATIVE SET for the activity instead — the behaviour the price dialog has, which is safe there because the dialog always renders and resends every subsidiary. Then a subsidiary of the project without an entry dated today or earlier has EVERY row dated today or earlier removed — its whole price history, not only the price in force — and falls back to the price described on group-internal-price. Future-dated rows are never removed by omission. Deleting history changes past billing, not only future billing: work is priced as of the date it was reported, so removing a row that was in force in March changes what March work still to be invoiced costs. That is why it is opt-in here: an integration sending a partial set has no way to know what it removed. Each entry upserts on (activity, subsidiary, valid-from). A future-dated entry replaces any existing future-dated price for that subsidiary, because a subsidiary can have at most one future price per activity. Under replace-all, note what this means for scheduling, because it is the case most easily got wrong: an entry dated in the future does not count as a price for today. Scheduling a rise for one subsidiary by sending only that one future-dated entry therefore removes the current price of EVERY subsidiary on the activity, including the one being scheduled, until the new date arrives. To schedule a change and keep today's prices, send each subsidiary's current entry alongside the future one. The price dialog does this for you; over the API it is explicit. The mirror image is worth knowing too: an entry dated in the past DOES count as a price for today, so it protects the subsidiary from clearing — but it does not change what is charged today if a later row already exists. Such a call is accepted and changes nothing visible. The offset into the full result that this page represents, 0-indexed. The size that this page was limited to. May have been automatically adjusted compared to user input. This value also always represents the number of returned rows. The total size of all rows. May be used to calculate number of calls required to fetch full result. A bank validate request is used to validate account information according to our internal logic. Select what you want to validate. Validate a BIC and IBAN Validate an account as it would be entered when creating a supplier invoice. Did the validation pass? Please note that a passing validation does not guarantee that the specific account actually exists, it merely means that it passed all passive validation rules such as check digits etc. Used when validation fails to supply a human-readable failure message. Always an empty string when validation passes. If set to true, the following validations are performed: * Bank transaction's full amount must be accounted for * All references revenues must be fully consolidated Recommended to always set this to true for use cases when it is expected that a bank transaction only represents revenues that are paid in full. Information about a revenue and a currency that should be consolidated. If a revenue was created with many different currencies, this element may be repeated. Reference to the revenue to be consolidated. Amount from the bank transaction that this revenue represents, as given in the bank account's currency. For example, if the bank account under consideration is in USD, the amount should be given in the same currency. The amount to consolidate as given in a currency used by the revenue. If more than one currency needs to be consolidated for a single revenue, the revenue can be repeated. If the used currency is fully consolidated with respect to the revenue's remaining amount, currency win/loss will be automatically performed. At least one file must be given, to use as basis for the accounting. Its format must be PDF. The general contract of this construction is that all the given bank transactions and revenues will be fully consolidated. Reference to a revenue to be consolidated. Reference to a bank transaction to be consolidated. If amounts from a previous ledger is known it can be specified here along with a desired account number to be credited. An optional currency win/loss amount that is used for sanity check the final result. At least one file must be given, to use as basis for the accounting. Its format must be PDF. Revenue transaction fees. If there is VAT associated with the fees given in the amount field, use this field to specify. This VAT represents an amount that is assumed to have already been subtracted from bank-transaction-amount. Number of consolidated bank transactions. Number of consolidated revenues. Total accounting amount of consolidated bank transactions. Total accounting amount of consolidated revenues. Reference to the client invoice. Reference to the revenue. Reference to the supplier invoice. The native amount given in a currency used by the distribution. Not set when the amounts are accumulated over the requested period. Zero based, so January is 0 and December is 11. Not set when the amounts are accumulated over the requested period. In hundredths of the accounting currency, so 123,45 is 12345. Only set when the amounts are broken down per dimension entry.