SELECT INTO Statement fails with arithmetic overflow but SELECT Statement runs without errors

Currently I have a strange problem and I need clarification (for my mind). Problem description: Today I found a stored procedure which runs two statements. First it drops a table and later it recreates this table again with a SELECT INTO statement. The stored procedure is part of our BI nightly runs and today throws a exception. The exception which was thrown was: 8115 Arithmetic overflow while convert numeric to numeric. --- Normaly when this kind of error happens we have a value which is to big to fit in a smaller datatyp and we try to cast the value to this datatyp. For example lets say we have the value 12345,12 and we want to cast this to decimal(6,2). This wont work and throw this error. Normaly when this happens I do this

ANSI_WARNINGS, ARITHABORT OFF;

and search the result for NULL values to further analyse the values. But this time there are no null values. And the second interessting thing is, if I remove the INTO part of the SELECT INTO statement there is no error. So this exception only occurs when the statement is executed as SELECT INTO. If the same statement is executed as SELECT the error is gone. --- I have tried multible things now to narrow this: * I have tried to change the cast statement to a try_cast statement **and this works** (also with the SELECT INTO (and with no NULLs in the result) -> So the try_cast does exactly what we want the cast to do. Is there a difference? * I have tried to convert the value to varchar and find the decimal sepperator position of each value to check if there is a value which is bigger than expected (which is not the case). -> The highest number I get was 10 so we have 9 digites to the left of the comma and we use decimal(12,3) here, which should be fine. * I have tried to change the cast from decimal(12,3) to decimal(13,3) **which works too** but make no sense to me because the maximum decimal seperator is 9. --- To fix the problem I now have changed the cast to a try_cast and the procedure is working again, so no time preasure for me. **BUT** I want to understand what happens here, because otherwise I think my brain will explode. --- Some sample information: I try to give you a smaller test SQL Statement because the BI Statement is relativ big. So the SELECT INTO Statement in the procedure looks something like this:

SELECT	cast(isnull(t1.IstGesamt / nullif(t1.SollGesamt, 0) - 1, 0) as decimal(12,3)) as AbwGesamt
	INTO	[dwh_global].[FaktAuftragszeit]
	FROM (
		SELECT	(a.ZEIT_JE_EINHEIT*a.AUFTRAGSMENGE) + a.RUESTZEIT as SollGesamt,
				a.BEARBEITUNGSZEIT_IST as IstGesamt
		FROM		 [ods_am].a
				join [ods_am].b ON (...)				
        WHERE b.auftragsart  'WAR'	
		 ) t1

The valuetypes are: * a.ZEIT_JE_EINHEIT -> numeric(8,3) * a.AUFTRAGSMENGE -> numeric(10,3) * a.RUESTZEIT -> numeric(8,3) * a.BEARBEITUNGSZEIT_IST -> numeric(11,3) The maximum value I get when I change the CAST to TRY_CAST is 450948999.000 (and no NULL Values). So this should be the maximum value and I think I should be able to cast 450948999.000 to decimal(12,3), correct? --- Is here maybe someone which knows what this can be and point me to the correct direction? Do I have forgoten something to analyse? As I mention I found a workaround but I want to understand this issue. Thank you in advance! --- UPDATE (Add Execution Plan): Plan for SELECT INTO Plan for SELECT Looks kind of similar expect the parallelism steps. The selected step is the one which filters the Auftragsart.

b.auftragsart  'WAR'

--- UPDATE (Add Execution Plan as XML) Here we have the Execution Plans as XML uploaded to Paste the Plan. First the one for the SELECT. Paste the Plan - Select And the second one is the one for the SELECT INTO. Paste the Plan - Select Into